Repository navigation
Display cause chain when alternate format is used #98
Description
As thiserror is complementary to anyhow, and anyhow supports {:#} format, would be nice if thiserror errors supported it too. This way in codebases that mix thiserror and anyhow errors, it would be possible to use {:#} everywhere and get cause chains printed for all errors.
Activity
tailhook commentedon Oct 14, 2020
I also need this. Do you want me to make a PR?
tailhook commentedon Oct 14, 2020
On the other hand, if you wrap the error into anyhow again, you can have it printed nicely without
thiserror's support. Just need to make sure that when doing.downcast_ref()the original error is printed instead of downcasted.link2xt commentedon Oct 14, 2020
I like the approach proposed in dtolnay/anyhow#111 more than this one, actually. Just change anyhow and thiserror to print causes by default and make
{}the same as{:#}.tailhook commentedon Oct 14, 2020
It's hard to say. I like to be able to do both. I.e. when printing vertically or when printing error messages together with backtraces.
I don't mind if
{}meant with causes but{:#}meant without (i.e. opposite than what we have now). But since a lot of applications are probably relying on current behavior it's weird to change now.Other reasons to keep current behavior:
{:#}is similar to{:#?}by meaning: longer more detailed output#[error("some text with {}", values)], it's intuitive thatDisplayshows onlysome text with values. If it adds: some longer thing: and another oneto the output and you need{:#}"to do what I meant" it looks weird.[-]Display cause chain when alternate formate is used[/-][+]Display cause chain when alternate format is used[/+]koivunej commentedon Jan 24, 2024
I see #233 was closed in favor of using
anyhowas the error reporter and so gaining access to{:#}but this issue is still open. I agree about the rationale of keepingthiserrorclean of "reporting", but at the same time, this is a caveat we need to remember or fix after when pieces of code migrate away from usinganyhowto matchable errors.{:#}cannot be bolted on by users of the crate; a formatting fn like we have report_compact_sources, but that is easy to forget. Would a PR introducing thisalternateif the impl would be calling back intothiserroron a#[doc(hidden)]function for the reporting be welcome?Sytten commentedon Sep 24, 2024
This would be very useful. Sometimes it is not practical to do a detour via anyhow.
Ralith commentedon Nov 6, 2024
+1, if you're directly reporting an error produced by external code, wrapping it in
anyhowor applying other custom logic is awkward and very easy to forget. In practice this has, for me, meant countless instances of errors being printed without necessary details, costing significant debugging time over the years.error: Print error strings in `thiserror` formatting implementation
win: Include `hresult` when printing "`Other`" error
MarijnS95 commentedon Dec 11, 2025
In #214 (comment) (closed because of being a duplicate of this issue) I linked a few more issues that are related or duplicates of this one:
(And perhaps more that were opened later)
win: Include `hresult` when printing "`Other`" error