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

Cookbook ideas for error-chain crate #184

Closed
aturon opened this Issue Jun 6, 2017 · 8 comments

Comments

Projects
None yet
7 participants
@aturon

aturon commented Jun 6, 2017

Come up with ideas for nice introductory examples of using error-chain, possibly in combination with other crates, that would be good to show in the Rust Cookbook. Please leave a comment here with your ideas! You don't necessarily have to write the example code yourself but PRs are always welcome!

edit

@brson brson added the tracking issue label Jun 7, 2017

@budziq

This comment has been minimized.

Show comment
Hide comment
@budziq

budziq Jun 7, 2017

Collaborator

@aturon This one might be a little tricky as over half of our examples already use error-chain.
It might be hard to come up with a "non-forced" example that shows something new without intimate knowledge.

Maybe some usage of chaining-errors?

cc @brson @Yamakaky

Collaborator

budziq commented Jun 7, 2017

@aturon This one might be a little tricky as over half of our examples already use error-chain.
It might be hard to come up with a "non-forced" example that shows something new without intimate knowledge.

Maybe some usage of chaining-errors?

cc @brson @Yamakaky

@Yamakaky

This comment has been minimized.

Show comment
Hide comment
@Yamakaky

Yamakaky Jun 7, 2017

Contributor

Yeah, using it everywhere should be good. Maybe just add an error chain centered example ? Like "this thing would be easier with error chain, here is how to do it".

Contributor

Yamakaky commented Jun 7, 2017

Yeah, using it everywhere should be good. Maybe just add an error chain centered example ? Like "this thing would be easier with error chain, here is how to do it".

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 15, 2017

Contributor

I agree this one probably doesn't need a lot, but maybe it's possible to formulate recipe statements based off of common problems newbies have with errors.

e.g.

  • "Handle errors correctly in main"
  • "Avoid discarding errors during error conversions"

idk

Contributor

brson commented Jun 15, 2017

I agree this one probably doesn't need a lot, but maybe it's possible to formulate recipe statements based off of common problems newbies have with errors.

e.g.

  • "Handle errors correctly in main"
  • "Avoid discarding errors during error conversions"

idk

@Yamakaky

This comment has been minimized.

Show comment
Hide comment
@Yamakaky

Yamakaky Jun 16, 2017

Contributor

Yeah, sure.

Contributor

Yamakaky commented Jun 16, 2017

Yeah, sure.

@KodrAus

This comment has been minimized.

Show comment
Hide comment
@KodrAus

KodrAus Jun 18, 2017

For newbies even just defining an error and using it seems like a useful example.

KodrAus commented Jun 18, 2017

For newbies even just defining an error and using it seems like a useful example.

@Michael-F-Bryan

This comment has been minimized.

Show comment
Hide comment
@Michael-F-Bryan

Michael-F-Bryan Jun 20, 2017

Contributor

I'd say something like defining an error type, then linking it to a couple other errors like std::io::Error or adding a couple custom variants is enough for a basic example. Then you can show an example of opening a file, using ? and/or chain_err() to bubble up any errors encountered. That's about as much as I've needed to do for most of my crates.

Another thing which may or may not be useful is printing a "backtrace" which looks something like this:

writeln!(stderr, "error: {}", e).unwrap();

for e in e.iter().skip(1) {
    writeln!(stderr, "\tcaused by: {}", e).unwrap();
}

(possibly swapping out unwrap() with ok())

When making command line apps, I've sometimes done something like that when there was a fatal error and the --verbose flag is passed in.

Contributor

Michael-F-Bryan commented Jun 20, 2017

I'd say something like defining an error type, then linking it to a couple other errors like std::io::Error or adding a couple custom variants is enough for a basic example. Then you can show an example of opening a file, using ? and/or chain_err() to bubble up any errors encountered. That's about as much as I've needed to do for most of my crates.

Another thing which may or may not be useful is printing a "backtrace" which looks something like this:

writeln!(stderr, "error: {}", e).unwrap();

for e in e.iter().skip(1) {
    writeln!(stderr, "\tcaused by: {}", e).unwrap();
}

(possibly swapping out unwrap() with ok())

When making command line apps, I've sometimes done something like that when there was a fatal error and the --verbose flag is passed in.

@budziq

This comment has been minimized.

Show comment
Hide comment
@budziq

budziq Jun 20, 2017

Collaborator

@Michael-F-Bryan looks like your idea is on the spot. Although I would suggest splitting it to three separate examples of growing complexity based on the feedback so far:

  • "Handle errors correctly in main" - super simple example which defines 1 error variant instead of using Box
  • "Avoid discarding errors during error conversions" - slightly more complex example showing aggregation of custom and crate errors that might use chain_err
  • "Obtain backtrace of complex error scenarios" - some realistic 3 level error handling (possibly based on largely stripped down version of Download a file example without tempdir/headder noise)

@brson @aturon do these look ok to you? If yes I'll create the specific issues and update the tracking issue.

Collaborator

budziq commented Jun 20, 2017

@Michael-F-Bryan looks like your idea is on the spot. Although I would suggest splitting it to three separate examples of growing complexity based on the feedback so far:

  • "Handle errors correctly in main" - super simple example which defines 1 error variant instead of using Box
  • "Avoid discarding errors during error conversions" - slightly more complex example showing aggregation of custom and crate errors that might use chain_err
  • "Obtain backtrace of complex error scenarios" - some realistic 3 level error handling (possibly based on largely stripped down version of Download a file example without tempdir/headder noise)

@brson @aturon do these look ok to you? If yes I'll create the specific issues and update the tracking issue.

@AndyGauge

This comment has been minimized.

Show comment
Hide comment
@AndyGauge

AndyGauge Apr 24, 2018

Collaborator

Closing tracking issue. All requested recipes are complete.

Collaborator

AndyGauge commented Apr 24, 2018

Closing tracking issue. All requested recipes are complete.

@AndyGauge AndyGauge closed this Apr 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment