|
@Brittain_Ben | |||||
|
Migrating our large rust codebase from failure to anyhow/thiserror has been considered a large QoL improvement.
I'd recommend investing time into doing the conversion.
|
||||||
|
||||||
|
Benjamin Brittain
@Brittain_Ben
|
7. sij |
|
cc/ @davidtolnay
|
||
|
|
||
|
Craig Tiller
@invalidop
|
7. sij |
|
Can you expand on how QoL has improved?
|
||
|
|
||
|
Benjamin Brittain
@Brittain_Ben
|
7. sij |
|
Multiple people have reached out about the improved readability of error messages.
We interop with the standard trait now.
We have a clean split between dynamic and structured error handling.
|
||
|
|
||
|
Benjamin Fry🦀👾⚙️
@benj_fry
|
8. sij |
|
Honestly, I’m highly tempted to just drop back to std Error at this point. The number of time I’ve converted is getting a bit onerous.
|
||
|
|
||
|
Benjamin Brittain
@Brittain_Ben
|
8. sij |
|
std::error::Error is totally usable now! Maybe use `thiserror` to generate nice structured errors though.
|
||
|
|
||
|
Guillaume Gomez
@imperioworld_
|
8. sij |
|
Urg, this whole error debate again... Using just the std errors was good enough for me and I don't have to migrate once a year to a new preferred way to handle them. :)
|
||
|
|
||
|
Benjamin Brittain
@Brittain_Ben
|
9. sij |
|
Using std::error::Error is acceptable to me now! It wasn't in the past, but is good now.
thiserror is a good choice for elegantly making those errors.
anyhow is nice if you have dynamic errors.
I don't feel this guidance is in conflict with your sentiment.
|
||
|
|
||
|
Jingjing Duan
@duanjingjing
|
16. sij |
|
Is there a blog post written about this migration?
|
||
|
|
||
|
Benjamin Brittain
@Brittain_Ben
|
16. sij |
|
Nope, but I'm more than happy to answer any questions you may have
|
||
|
|
||
|
ugh
@nvll
|
7. sij |
|
But literally everyone including you told me to use failure!
|
||
|
|
||
|
Benjamin Brittain
@Brittain_Ben
|
7. sij |
|
That was a while ago though! std::error::Error wasn't ready yet
|
||
|
|
||