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

A generic way to wrap errors would be useful in the standard library #14419

Closed
glandium opened this issue May 25, 2014 · 3 comments
Closed

A generic way to wrap errors would be useful in the standard library #14419

glandium opened this issue May 25, 2014 · 3 comments

Comments

@glandium
Copy link
Contributor

It would be useful in functions that can fail in different ways from the functions it calls itself, allowing something like:

fn func() -> Result<T, Error> {
  try!(may_return_error_type_A);
  try!(may_return_error_type_B);
}
@eddyb
Copy link
Member

eddyb commented May 25, 2014

trait WrapError<T> {
    fn wrap_error(e: T) -> Self;
}
impl<T> WrapError<T> for T {
    fn wrap_error(e: T) -> T {e}
}
fn wrap_error<T, E: WrapError<T> = T>(e: T) -> E {
    WrapError::wrap_error(e)
}
macro_rules! try(
    ($e:expr) => (match $e { Ok(e) => e, Err(e) => return Err(wrap_error(e)) })
)

This would be backwards-compatible and allow the user to add custom wrappers - even have #[deriving(WrapError)] on enums.
Too bad it requires better coherence - see rust-lang/rfcs#48 - and something like #13702 for the default in wrap_error's definition (without which the change to try! is a backward-compat hazard).

@aturon
Copy link
Member

aturon commented Aug 15, 2014

cc rust-lang/rfcs#201

@ghost
Copy link

ghost commented Nov 11, 2014

This is now implemented, closing.

@ghost ghost closed this as completed Nov 11, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
fix: Fix proc-macro paths using incorrect CrateId's for `rust-project.json` workspaces
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants