The Missing Piece in Rust Error Handling
18 points by snej
18 points by snej
Wow, this is very cool, thanks so much for sharing! I've had this exact frustration with error types before and this seems like a really nice way to handle it. The ability to define errors as a small set of them that actually can occur at a given call instead of packing it into module-level enum with irrelevant errors is so nice for being able to refine what actually happens. I'm very excited to give this a go!
Another annoyance that I've run into for error handling is that it is annoying to write code that returns multiple errors. Say you're writing a backend CRUD application and you have to verify the fields of a create request. It would be nice to be able to return all fields that were in violation of the constraints rather than just the one, but it's difficult to do that with Result since ? returns early. I've seen some solutions using some sort of error vec crate, but they've never felt very elegant to me. I'm curious to see if some constructs in this crate have any hints at a solution.
This looks fantastic! Is there a downside?
I'm vaguely wondering if there could be an anyhow adapter so you could transform errors into this when you call existing code.
I would've said a downside would be that you'd have to order your types in a certain way for e.g. .widen() and .narrow()... But it seems like it works regardless of ordering? The eros library seems to have a bunch of hacks tech to make your errors an actually unordered set.
Maybe compiler errors are a downside? I haven't tested it, but I'd suspect that if you happen to specify the same type twice / accidentally specify non-error-types / similar invalid combinations?
Regardless, I'd love to read a blog post about how all of this works.