I'm currently rather unhappy with the error handling in crate, which is partially a result of me writing error handling code rather carelessly in this repo due to my time constraint and the size of the protocol, and the fact that I'm not completely happy with most error handling crates anyway.
Either find one that has everything listed below or implement our own:
Clean code. The dream would be to just have an enum and not a struct, but obviously the backtrace information is relevant. Maybe this could also be alleviated by using a different Result type implementing the carrier trait or even dereferencing to the regular result type. (The main downside to this would be that in the event that you forget to use OurResultType you will get nasty issues because the one from the default prelude will be used instead.) Maybe this could even be made in such a way, that in release builds the backtrace field is zero sized.
Derive from other errors. If you ask me it doesn't even have to do everything automatically, I'd be fine writing the display() method for my new error manually. This would allow us that fancy better derives crate (or what it's name was).
More to come.
This is not really a concern right now but will be in the future: add a way to make exposing the error safe to additions and changes without breaking semver in every case.
I'm currently rather unhappy with the error handling in crate, which is partially a result of me writing error handling code rather carelessly in this repo due to my time constraint and the size of the protocol, and the fact that I'm not completely happy with most error handling crates anyway.
Either find one that has everything listed below or implement our own:
Clean code. The dream would be to just have an enum and not a struct, but obviously the backtrace information is relevant. Maybe this could also be alleviated by using a different Result type implementing the carrier trait or even dereferencing to the regular result type. (The main downside to this would be that in the event that you forget to
use OurResultTypeyou will get nasty issues because the one from the default prelude will be used instead.) Maybe this could even be made in such a way, that in release builds the backtrace field is zero sized.Derive from other errors. If you ask me it doesn't even have to do everything automatically, I'd be fine writing the display() method for my new error manually. This would allow us that fancy better derives crate (or what it's name was).
More to come.
This is not really a concern right now but will be in the future: add a way to make exposing the error safe to additions and changes without breaking semver in every case.
maybe: https://github.com/withoutboats/failure is an option