Rust already has most of what I want from error handling: explicit control flow, errors as values, and concise propagation with ?. The friction comes when deciding what to put in the error half of Result. We often end up choosing between precise types that require boilerplate and convenient types that hide which errors can occur. But precision and convenience do not have to be competing goals. Error types should compose as easily as the functions that return them.
IIUC this is essentially anyhow with compile time type tags. The only thing I would worry about is how long it will take to compile, since the traits look a bit difficult to solve.
Well that mean incremental compilation is still fast. But look at the numbers, first time compilation is apparently taking 2-4x as long compared to anyhow. And I think if you want a more like-for-like comparison you should look at thiserror rather than anyhow. And I would also very much interested to see how the compile time grows w.r.t. number of error types in the union.
To my inexpert eye it looks like the subset search (the aforementioned unordered set trick) is quadratic to solve — but at least not exponential, and perhaps not a problem with a typical number of error types in the set? (I also see it’s arbitrarily limited to 26 error types, because the tuple generics have to be done explicitly.)
OCaml has this approach to errors built-in thanks do its polymorphic variants feature. The downside in my experience is that when one can more easily make unions between sets of errors one will take that approach. Without that point where the programmer is given a moment to explicitly design the error it tends to end up under-designed, lacking any additional useful context that could have been added otherwise.
Author here. The only downside in my opinion is that is does not work on no_std without alloc. But even this I just figured out with the inspiration of a colleague. Hopefully a PR for this will be up in the coming days – A lot of pieces to get right and conditional compilation, but the api will be the same. Overall for eros, I meticulously designed the api and am very happy with it. Full flexibility to the developer.
This looks fantastic! Is there a downside?
I’m vaguely wondering if there could be an
anyhowadapter so you could transform errors into this when you call existing code.score 1 · canonical
IIUC this is essentially anyhow with compile time type tags. The only thing I would worry about is how long it will take to compile, since the traits look a bit difficult to solve.
score 1 · canonical
Somone just benchmarked this. After the first compilation, the same as time as anyhow. https://github.com/dpc/eros-bench
score 1 · canonical
Well that mean incremental compilation is still fast. But look at the numbers, first time compilation is apparently taking 2-4x as long compared to anyhow. And I think if you want a more like-for-like comparison you should look at thiserror rather than anyhow. And I would also very much interested to see how the compile time grows w.r.t. number of error types in the union.
score 1 · canonical
To my inexpert eye it looks like the subset search (the aforementioned unordered set trick) is quadratic to solve — but at least not exponential, and perhaps not a problem with a typical number of error types in the set? (I also see it’s arbitrarily limited to 26 error types, because the tuple generics have to be done explicitly.)
score 1 · canonical
OCaml has this approach to errors built-in thanks do its polymorphic variants feature. The downside in my experience is that when one can more easily make unions between sets of errors one will take that approach. Without that point where the programmer is given a moment to explicitly design the error it tends to end up under-designed, lacking any additional useful context that could have been added otherwise.
score 1 · canonical
Author here. The only downside in my opinion is that is does not work on
no_stdwithoutalloc. But even this I just figured out with the inspiration of a colleague. Hopefully a PR for this will be up in the coming days – A lot of pieces to get right and conditional compilation, but the api will be the same. Overall for eros, I meticulously designed the api and am very happy with it. Full flexibility to the developer.Yes there is an anyhow adapter behind the
anyhowfeature flag https://github.com/mcmah309/eros#anyhowscore 1 · canonical