-
Notifications
You must be signed in to change notification settings - Fork 60
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
Support a backtrace #11
Labels
enhancement
New feature or request
Comments
I decided to create a parallel |
Postponing this. |
shepmaster
added a commit
that referenced
this issue
Feb 4, 2019
shepmaster
added a commit
that referenced
this issue
Feb 4, 2019
shepmaster
added a commit
that referenced
this issue
Feb 4, 2019
shepmaster
added a commit
that referenced
this issue
Feb 4, 2019
shepmaster
added a commit
that referenced
this issue
Feb 4, 2019
shepmaster
added a commit
that referenced
this issue
Feb 5, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
People like backtraces.
My idea is to support a field called
backtrace
. If it's present, it will be automatically constructed whenFrom::from
orfail
is called.One trick will be to decide how best to have forwards-compatibility. Eventually, the standard library will have such a type and it will accessible via the
Error
trait, but it's not there today. We'd prefer to be able to be able to seamlessly upgrade.My thought is to have a newtype for the backtrace crate that doesn't expose much in the way of an API. We can then add an inherent method on the
Error
enum with the proposed API forstd::error::Error
.Things to check / consider:
std::error::Error
gains the method; will that cause conflicts?The text was updated successfully, but these errors were encountered: