2 ms·
I would describe Rust's error handling crisis more as: 1. I'll just handle all of the errors by having my functions return Result<T, E> where E is some type th
by TheCoelacanth 8y ago
I would describe Rust's error handling crisis more as:
1. I'll just handle all of the errors by having my functions return Result<T, E> where E is some type that encapsulates all of different error conditions that can happen in my function.
2. Function one returns Result<T1, E1> and function two returns Result<T2, E2>. What type do I use for a function that calls both and just uses `?` to defer handling on errors from either function? Guess I either have to use Box<Error> and do a bunch of ugly downcasting whenever I want to handle an error or I have to write a bunch of code to define another error type E3 which combines E1 and E2 and I have to implement From<E1> and From<E2> so now I have more code just for defining error types and conversions than I have for actually doing anything.
3. Create complicated macros like error_chain[1] or failure[2] to try to cut down on boilerplate in #2.
[1] https://docs.rs/error-chain/0.12.0/error_chain/ https://docs.rs/error-chain/0.12.0/error_chain/
[2] https://docs.rs/failure/0.1.2/failure/ https://docs.rs/failure/0.1.2/failure/
- marcosdumay 8y ago> Guess I either have to use Box<Error> and do a bunch of ugly downcasting ... or I have to write a bunch of code to define another error type... Yes, that's the monadic equivalent to `catch(E1 e) {handle e}; catch(E2 e) {handle e}; catch(E3 e) {handle e}...` On practice things get all over the place, with some times the exception being more concise and other times they being way more verbose. But the problem to be solved is not verbosity, it's with implicit code catching you by surprise, with too generic handlers on code that can't reasonably handle an error, and some issues with how errors interfere with code composition.