Reimplement as procedural macro?
inodentry opened this issue · 3 comments
quick-error is by far my preferred error handling solution in Rust. I like it more than failure or error-chain. However, it is a shame that its functionality is limited due to limitations of the macro_rules syntax. For example: lack of generics support (issue #20). Also: poor error messages.
I believe these issues could be resolved if quick_error was implemented as a procedural macro, which is now stable as of Rust 1.30. This would greatly improve the usefulness of the crate, at least for projects that don't mind the 1.30 minimum Rust version requirement.
It could be released as a new semver-incompatible version to avoid bumping the minimum Rust requirement of old code that depends on this crate to 1.30 due to automatic upgrade.
Hi! While I have nostalgia to the quick-error I don't think it makes sense to continue developing the crate. Using derives and attributes like in failure makes much more sense nowadays. This is even more true with current attempts to move important parts of failure crate into stdlib and maybe even provide generic derive(Display) in stdlib.
Also, given the trade-off we've made here because of the limitations of macros and because major version bump is needed anyway, the new library can be designed from the ground up wih nicer syntax and modern semantics.
Fair enough. I understand.
I just personally dislike failure, because it does not derive From impls (which makes it very impractical) and also bundles a fancy Error abstraction with backtraces, etc, which I find unnecessarily complex to bring into everything. I like the simplicity of this crate. It just simply derives what I want.
I hope that whatever makes it to the stdlib in the future is a good replacement in the same minimalist spirit.
Do you, by any chance, know where activity about these "current attempts" at improving error handling is happening? Could you point me to the right place? Maybe I could contribute.
I just personally dislike failure, because it does not derive From impls
Yes, there is an issue about it. Maybe you can upvote it or maybe derive_more crate is better? (i.e. more fine grained control)
also bundles a fancy Error abstraction with backtrace
It's only if you use failure::Error type which is not requirement. I use Fail for most library errors. Only unrecoverable errors might carry a traceback and the cost isn't much in this case (e.g. restarting process is much more expensive anyway)
Do you, by any chance, know where activity about these "current attempts" at improving error handling is happening? Could you point me to the right place? Maybe I could contribute.
Perhaps, this is the right entry point.