Retiring anomaly

[tarcieri]

FYI, I'm planning on deprecating the anomaly error handling crate, which tendermint-rs presently uses.

There have been a number of error handling crates that have surpassed it coming out of the error handling working group.

I would suggest eyre as a replacement.

[romac]

Great news! Will abscissa move to eyre as well? If so, any ETA on that?

[tarcieri]

@romac I believe @yaahc has a branch which moves Abscissa to (color-)eyre but I'm not sure about the status of that

[tarcieri]

FYI, here's an example of moving from anomaly to eyre: iqlusioninc/crates#555

[romac]

@tarcieri Thanks for the pointers!

PS: By the way, by "great news" I didn't mean to imply that anomaly was a bad library, but rather that since the ecosystem seems to have moved away from it in favor of eyre (something I've been considering doing for our libs as well), I was happy to see that you were now recommending it as well over anomaly.

[tarcieri]

No worries, I’m happy there are better libraries emerging in this space as well

[ebuchman]

Re #160 (closed for this issue) we should still write a small ADR for error handling in the repo. The comment #150 (comment) provides a great starting point for an ADR. Also relevant #158 (comment)

[DaviRain-Su]

Can we use anyhow to handle error?

[tony-iqlusion]

Some other downstream projects have switched to eyre, which is a fork of anyhow. eyre supports adding arbitrary context objects to errors.

I don't believe it supports the same hacks as anyhow to work in no_std contexts (I'm surprised to learn those actually landed). Instead, my understanding is a no_std path for eyre relies on actually moving the Error trait into libcore, which is currently blocked on exposing Backtrace from libcore: rust-lang/rust#77384

[yaahc]

I don't believe it supports the same hacks as anyhow to work in no_std contexts (I'm surprised to learn those actually landed). Instead, my understanding is a no_std path for eyre relies on actually moving the Error trait into libcore, which is currently blocked on exposing Backtrace from libcore: rust-lang/rust#77384

I'm not sure if they added new hacks but there was some no_std support originally that we tried bringing over with eyre but I think it was broken at the time, not sure. I don't recall removing it but I may have. Either way yea, I don't personally plan on implementing any hacks for no_std but I think any hacks that work for anyhow could be applied to eyre and so I'd likely merge any PR's to bring them back to feature parity, since my goal with eyre is always to be a drop in replacement for anyhow with more customizable reporting.

[tony-iqlusion]

If there's a path to getting the Error trait into either libcore or liballoc, it seems like waiting for that is the right way to go with eyre

[yaahc]

If there's a path to getting the Error trait into either libcore or liballoc, it seems like waiting for that is the right way to go with eyre

Sure, but what I mean is that the no_std support that anyhow provides is already independent of the Error trait, you can only use anyhow::Error and construct them from Display types iirc. Alongside that you still need alloc support to use anyhow/eyre. So I think whether we wait for Error in core or not really depends on what you mean by getting libcore or liballoc support. It may be that the support provided by anyhow is already insufficient or that the support you need from eyre is already very nearly there.

[tony-iqlusion]

In no_std mode, anyhow defines its own private (fake) StdError trait in absence of a real std::error::Error trait:

https://github.com/dtolnay/anyhow/blob/704622f/src/lib.rs#L265-L270

Since it's not re-exported, it's not possible to use dyn Error, and with it Box<dyn Error> even when liballoc is available.

[yaahc]

Ack, that's what I remember it having. That's what I was referring to when I said you can only construct anyhow::Error with Display types, the Error based APIs via Error::new and Error::from both get disabled when compiled for no_std. Just checked and we did actively remove that, and I'm guessing that adding back just that wouldn't be the easiest thing. Now you have me wondering if there's a low hanging fruit of moving the error trait just into liballoc that could be done today that would enable anyhow and eyre to use Error in no_std.

[tony-iqlusion]

Now you have me wondering if there's a low hanging fruit of moving the error trait just into liballoc that could be done today that would enable anyhow and eyre to use Error in no_std.

That would be amazing!

[DaviRain-Su]

Ack, that's what I remember it having. That's what I was referring to when I said you can only construct anyhow::Error with Display types, the Error based APIs via Error::new and Error::from both get disabled when compiled for no_std. Just checked and we did actively remove that, and I'm guessing that adding back just that wouldn't be the easiest thing. Now you have me wondering if there's a low hanging fruit of moving the error trait just into liballoc that could be done today that would enable anyhow and eyre to use Error in no_std.

cool, amazing.

[DaviRain-Su]

@yaahc Want to know if you've fixed this feature?

[yaahc]

@yaahc Want to know if you've fixed this feature?

It's not fixed yet, I forgot that the backtrace part of the Error api still needs a full solution rather than just a proof of concept proposal and getting that fully sorted is necessary before we could even do a partial move to alloc.

[DaviRain-Su]

It's not fixed yet, I forgot that the backtrace part of the Error api still needs a full solution rather than just a proof of concept proposal and getting that fully sorted is necessary before we could even do a partial move to alloc.

Thank you for your answer