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

Add richer error-handling constructs #434

Closed
aturon opened this issue Nov 3, 2014 · 4 comments
Closed

Add richer error-handling constructs #434

aturon opened this issue Nov 3, 2014 · 4 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@aturon
Copy link
Member

aturon commented Nov 3, 2014

The trait-based exception handling RFC was postponed for the 1.0 timeframe, but the core team and broader community are generally in favor of this design. We hope to revisit it shortly after the release candidate is produced.

@mitsuhiko
Copy link
Contributor

Is there a chance we could see a fail! macro before 1.0 that does what the error part of the try! macro does at least? The FromError trait is really convenient but currently it feels very much like something like fail! needs to be added.

Eg:

macro_rules! fail {
    ($expr:expr) => (
        return Err(::std::error::FromError::from_error($expr));
    )
}

@arthurprs
Copy link

fail! is a nice complement to try! +1 on that

@johanfange
Copy link

What about stack traces? Stack traces are immensely useful for diagnosing errors in large long-running applications.

Or is that an orthogonal feature?

@petrochenkov petrochenkov added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jan 19, 2018
@Centril
Copy link
Contributor

Centril commented Oct 11, 2018

We can probably close this now since there are so many various error handling proposals.

@Centril Centril closed this as completed Oct 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

6 participants