Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
msirringhaus.github.io
Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
1–10 of 204 posts
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#2as someone who works 95% of the time in rust, how to handle my errors is never a problem for me. I think the issue is the expectations of people coming into it with a different frame of reference, expecting the kind of traceback/exception framework built in - and for that to be a typical debugging workflow.
like 95 times out of 100, I just `.map_err(|e| /* code to convert e to return type's error... */)` and I'm done. the other 5 times I create a local error enum to represent the different types of error that can be returned.
most importantly, the overwhelming gladness I have that code somewhere deep in my stack can't throw an exception vastly outweighs the "pain" of the ongoing incremental work it takes to handle errors intelligently throughout my code.
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#3as someone who works 95% of the time in rust, how to handle my errors is never a problem for me. I think the issue is the expectations of people coming into it with a different frame of reference, expecting the kind of traceback/exception framework built in - and for that to be a typical debugging workflow. like 95 times out of 100, I just `.map_err(|e| /* code to convert e to return type's error... */)` and I'm done…
Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding.
With the anyhow crate, this problem is solved as well. Just use anyhow if you just want to try something out quickly without being slowed down by error type mismatches, and then later refine it to a handcrafted error type.
I prefer rust error handling over all other languages I worked with (scala, java, C++, C, javascript, typescript, ...).
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#4Error handling has been wrong since the beginning, and has continued to be wrong ever since.
First, we had error codes. Except these were wrong because people forget all the time to check them.
Then we had exceptions, which solved the problem of people forgetting to check by crashing the app.
Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exception, but caused an explosion in thrown exception signatures, culminating in "catch Throwable". Back to square one.
Then we got multi-return error objects, maybes, panics, and all sorts of bright ideas that fail to understand the basic premises of errors:
Any error system that relies upon developer discipline will fail because errors will be missed.
Any error system that handles all errors the same way will fail because there are some errors we can ignore, and some errors we must not ignore. And what's ignorable/retriable to one project is not ignorable/retriable to another.
Attempting to get the complete set of error types that any given call may raise is a fool's errand because of the halting problem it eventually invokes. Forcing people to provide such a list results in the Java problem for the same reason.
It's a hard problem, which is why no one has solved it yet.
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#5Error handling in Rust is the most appealing feature for me. Not performance. I really can not understand people who want to ignore error cases or write their code pretending that error will never happen. All of these "unwrap", "expect" sounds to me like "ok, there might be an error but I'm too lazy to write code to handle it so let's just hope it will never happen”.
Of course, when your code is full of “panic”s, then errors handling will be a mess, but it just means your code is a mess and you need to finally take care of the errors. ‘Result’ and ‘enum’ are the best friends in this.
By writing the code to handle errors you’ll find that many of them are recoverable; that some errors might look “critical” for one function and “insignificant” for another, so if you will not panic and just return this error, at some point of the path it will be recovered.
This post mentions some useful libraries for simplifying the errors tracing (with contexts), but the tone is too sarcastic, sounds close to hysterical.
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#6Error handling has been wrong since the beginning, and has continued to be wrong ever since. First, we had error codes. Except these were wrong because people forget all the time to check them. Then we had exceptions, which solved the problem of people forgetting to check by crashing the app. Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exc…
> It's a hard problem, which is why no one has solved it yet.
The way you described it seems not so much as hard problem. More like an impossible one.
That said. Perhaps error handling isn't one problem at all, but several problems masquerading as one. In which case Rust approach makes much more sense.
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#7as someone who works 95% of the time in rust, how to handle my errors is never a problem for me. I think the issue is the expectations of people coming into it with a different frame of reference, expecting the kind of traceback/exception framework built in - and for that to be a typical debugging workflow. like 95 times out of 100, I just `.map_err(|e| /* code to convert e to return type's error... */)` and I'm done…
Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding. With the anyhow crate, this problem is solved as well. Just use anyhow if you just want to try something out quickly without being slowed down by error type mismatches, and then later refine it to a handcrafted error type. I prefer rust error handling over all other languages I worked with (scala,…
for exploratory coding you can also just unwrap, assert, panic..
It's useful to remember that error handling is optional in those cases :)
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#8For the mostpart, Rust error handling is okay.
What really rustles my jimmies, however, is the often mandatory indentation because of a lack of an inverse "if let". I prefer to bail out of a block if a condition is NOT met, rather than execute another nested block if it IS met. Rust makes that harder than it should be. It's good code hygiene in every other language, and Rust makes it painful in places. I've even been stopped from doing this by literal bugs in the borrow checker.
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#9Error handling has been wrong since the beginning, and has continued to be wrong ever since. First, we had error codes. Except these were wrong because people forget all the time to check them. Then we had exceptions, which solved the problem of people forgetting to check by crashing the app. Then the Java team got the bright idea to have checked exceptions, which at first helped to mitigate crashes from uncaught exc…
The only system I think should completely go is Exceptions except in the case of termination or absolutely catastrophic failure - this isn't really about programming but rather that the implementation is a total pain, the compiler struggles to optimize them, and even better they make quite a few safety analyses like borrow checking very difficult because the control flow graph basically explodes when you start considering exceptional control flow - even on a basic block
Re: Where Everything Went Wrong: Error Handling and Error Messages in Rust (2020)
#10as someone who works 95% of the time in rust, how to handle my errors is never a problem for me. I think the issue is the expectations of people coming into it with a different frame of reference, expecting the kind of traceback/exception framework built in - and for that to be a typical debugging workflow. like 95 times out of 100, I just `.map_err(|e| /* code to convert e to return type's error... */)` and I'm done…
Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding. With the anyhow crate, this problem is solved as well. Just use anyhow if you just want to try something out quickly without being slowed down by error type mismatches, and then later refine it to a handcrafted error type. I prefer rust error handling over all other languages I worked with (scala,…
Completely agree. I used to create my own error type(s) manually and implement the various conversions for 3rd party crates and it was quite a lot of boilerplate but with anyhow (for applications where you don't really care about strict error types) and thiserror (when you need to be a little more thorough).
Actually that's effectively TFA's solution, if they had used thiserror/anyhow from the start there might not have been an issue to begin with. Admittedly it took me a while to find these crates since they're not part of std.
Maybe the community should come together to create a curated list of third party crates that should probably be known by all Rust devs? Crates like thiserror, anyhow, rand, serde, clap and other "de-facto standard" crates?