Open thomcc opened 6 years ago
Okay, after reading a tad more and talking to Thom, I understand why this works. As should have been obvious, just deriving a Fail trait won't provide our error enums with a place to store backtrace.
And so, something like this is basically what we'd want - a struct to host bunch of contextual information, a lightweight enum for actual error types, and some glue to tie it all together.
It's not clear to me why we need to Box stuff. You mentioned reducing memcpy traffic in case of large ErrorKinds, but in our case they're mostly just simple enums with an i64 or sometimes a String in them. Could you explain your reasoning here?
Otherwise, maybe a clean-up with some macros? That would either mean duplicating the macros in a bunch of places, or having them live in core
and growing an extra dependency in other crates (except edn
...), or adding a new lightweight macros
crate that we can re-use. I think the latter is the winner out of the three options.
This adds a lot of boilerplate which could be simplified by macros.
I was planning on cleaning this up before pushing it but here it is!
Caveat: I haven't tested this in versions of rust other than whatever i happen to be using by default right now! I did try to make the changes compatible with 1.25.0 (e.g.
&
/ref
noise in matches) but that was just to minimize future work and I might not have been thorough here