Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

alternate Display to include the source chain #390

Open
BugenZhao opened this issue Aug 4, 2023 · 4 comments
Open

alternate Display to include the source chain #390

BugenZhao opened this issue Aug 4, 2023 · 4 comments
Labels
enhancement New feature or request feedback requested User feedback desired on a design decision

Comments

@BugenZhao
Copy link

Hi, and thanks for your work on this great library!

I'm considering if it's possible to support displaying the source chain with alternate Display (i.e. {:#}), which seems to be a convention for error reporting utilized in many other error handling libraries, including anyhow and error-stack.

@shepmaster
Copy link
Owner

Does report or Report not work for you?

@BugenZhao
Copy link
Author

Yeah, it seems Report has a similar idea. However, I have several concerns...

  • I'm not sure if developers always remember to wrap the Error into Report before printing them out, or they'll lose the information from the sources if {source} is not included in #[snafu(display(..))] (which I guess should be a good practice?).
  • It looks like Report always includes the backtrace if provided, which might not be suitable to appear in a user-facing error message. As a result, we have to introduce our own Display wrapper.

@shepmaster
Copy link
Owner

I'm not sure if developers always remember

How would this be different from remembering to use the alternate display flag?

which I guess should be a good practice

The current best practice is to do exactly one of:

  • include the source in the Display implementation
  • link to the source via Error::source

Report always includes the backtrace if provided

Right now, it only happens on nightly Rust if you've enabled the unstable-provider-api feature flag, but at some point in the future it might happen by default. We might also add some small configuration knobs.

@shepmaster
Copy link
Owner

utilized in many other error handling libraries

I believe the big difference is that these other libraries (and I'm not an expert on them) don't actually give you control over the implementation of Display in the first place, while SNAFU does. For example, could you share your desired syntax to specify the regular and alternate Display implementations for a SNAFU-enhanced error?

We have had some discussions about some kind of #[snafu(display(false))] style option that would disable the creation of the Display implementation, letting the user define it completely by hand. That would allow uncommon / highly special cases without completely jettisoning SNAFU.

@shepmaster shepmaster added enhancement New feature or request feedback requested User feedback desired on a design decision labels Aug 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feedback requested User feedback desired on a design decision
Projects
None yet
Development

No branches or pull requests

2 participants