-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error Handling #2
Conversation
* Outline rationale and process in README.md * Bootstrap proposal template
Co-Authored-By: Kim Altintop <kim@monadic.xyz>
Co-Authored-By: Nuno Alexandre <nunombalexandre@gmail.com> Co-Authored-By: Rūdolfs Ošiņš <rudolfs@osins.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think thiserror
is what I actually wanted for librad
. A few questions, though:
- why is
anyhow
better suited to work in conjunction withthiserror
? - I'm not sure about the assertion point: is this about being able to write
assert!(matches!(...))
or? - I think it could be spelled out a bit more concretely what the recommendations / guidelines are for using this combo of libraries. To me, errors-as-values always boils down to the basic question: do I want the caller to implement control flow based on the error variant or not? In the latter case, how would I express this with
anyhow
+thiserror
? Is the recommendation to useBox<dyn Error>
(or a genericError(String)
variant) in libraries, andanyhow::Error
in application code? What about unifying aBox<dyn Error>
at a higher level?MyError::DunnoButItBroke(Box<dyn Error>)
?
@kim: Thanks for the feedback! I'll address the 3rd point by fleshing out the recommendation section more. Regarding the other two points, here's my thoughts.
In reality, any library that has interoperability with the However, I think something to keep in mind is that Otherwise, it's down to which set of functionalities we would prefer and What do you think? Also let me know if any of this info is useful for the proposal proper.
The assertion point is about the macros used for early return syntax rather than |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sick first draft. Left a bunch of suggestions for typos and a general question about the understanding of Option
.
I agree with @kim - examples of the recomnended stack, one for a lib and one for an app would help a lot.
Co-Authored-By: Alexander Simmerl <a.simmerl@gmail.com>
Co-Authored-By: Alexander Simmerl <a.simmerl@gmail.com>
Co-Authored-By: Alexander Simmerl <a.simmerl@gmail.com>
Co-Authored-By: Alexander Simmerl <a.simmerl@gmail.com>
Looks good to me so far -- I third the point that code examples of using the suggested stack in our context would be helpful. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Nothing to add
proposals/0001.md
Outdated
`struct` will be created to represent the custom error type. In the case of creating a library, | ||
these can be left public (`pub`) if they are fine to expose. In the case of opaque errors for which | ||
the library author wishes to prevent the end-user from doing any control flow, a combination of | ||
a `pub struct` and hidden fields is recommended. I believe this gives maximal control to the library |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also #[non_exhaustive]
, which I think is also a good recommendation: always force library consumers to be prepared for new variants / fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh interesting 🤔 I'll add this to the recommendation.
example of a file error but also introduce a deserialization error. | ||
|
||
```rust | ||
pub struct DeserializationError(SomeDeserializationError); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm ok. I think I would in practice have an internal error enum, and unify that at a higher level in a variant ContentsOfSausage(Box<dyn Error>)
. Because, with this solution you would end up with a lot of standalone structs only for the purpose of hiding the underlying error, or no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the struct can hide a private enum
of opaque errors. So whatever is in the opaque struct is up to you. Whether it's dyn Error
or something else, all it needs is the Error
derivation.
My point for having this opaque struct method is to still allow the library to handle the errors if it thinks it can, otherwise it'll eventually become a String
.
Would you agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I agree, but I suspect that I’d be too lazy to exercise this diligently XD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol, we can always amend ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine write-up, @FintanH ✌️
I would recommend you run this file through grammarly.com, mostly to add missing commas that make the text a bit harder to read at times.
String>` you can chain errors further by returning another `Err("Something went wrong")`. `String` | ||
can almost be seen as an "unstructured error" since we are able to place whatever we like inbetween | ||
the double-quotes. We can reverse pros and cons in contrast to structured errors. We avoid | ||
"structural hell" but we can't inspect any of the information (unless you parse, but please don't) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unless you parse, but please don't
this!
Co-Authored-By: Nuno Alexandre <nunombalexandre@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
📚 📀 🛎 ⌚️
Thanks, everybody ❤️ 🌱 |
This PR proposes how to make decisions around error handling in Rust and which packages to use for making our lives easier.