Concerns about error handling


#1

Hello. I have been writing a webserver based application in rust for the past year or so, but as the complexity has grown, I have started to run into problems with error handling. Initially, I was lazy and just used unwrap which is obviously the wrong way to do things, but it worked for a while. Eventually, I got around to switching to using error_chain.

However, I have now started to run into problems with this approach as well. Since the ? operator simply passes the error along, all information about where the error originated from is lost. For example, if a web request returns 404 I get that information, but not what request or function generated that.

Obviously, in this case I should use error_chain for actually chaining errors. However, this seems verbose and not without its own issues. Previously, I could simply use ? now I have to write .chain_err(|| <something>). For <something> there are two options, I either just use a string there which seems kind of ugly but works. I could also define many more error types for each sub-function but that would require a lot of extra work and chain_err(|| ErrorKind::ThisFunctionFailed.into()) is even more verbose.

I wouldn’t mind this if I got something more out of it, but right now, it feels like im doing a lot more work to get less information about errors than unwrap gives me. unwrap, gives me a backtrace with actual line numbers if run with RUST_BACKTRACE=1 and I can attach gdb to the panic handler to get more info. My current error_chain strategy either gives no information, or requires more work to give me a backtrace which does not contain line numbers or function calls and doesn’t allow me to jump into the failing function with gdb as easily.

Is there something I could do differently to make error handling nicer? One thing I can see myself doing is using something like the backtrace crate to add a backtrace to actual errors and propagate them through the code using ? but that feels wrong.

This is my current code if it is of interest https://github.com/thezoq2/flash/tree/feature/sync


#2

Have you looked into the failure crate? https://boats.gitlab.io/blog/post/2017-11-16-announcing-failure/
There’s still some boilerplate involved (depending on which approach you take) but might be worth looking into if you’ve yet to do so.


#3

Aparently not thoroughly enough, I didn’t know it has backtraces built into failure types. It looks like it has less boilerplate than error_chain as well so I’ll probably look into it, thanks.