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

Cleanup error type mapping in serde_snapshot #10580

Merged

Conversation

svenski123
Copy link
Contributor

Problem

Excessive explicit error type mapping is unclear

Summary of Changes

Rework error types to allow use of '?' operator without explicit map_err() calls

@codecov
Copy link

codecov bot commented Jun 15, 2020

Codecov Report

Merging #10580 into master will increase coverage by 0.0%.
The diff coverage is 45.4%.

@@           Coverage Diff           @@
##           master   #10580   +/-   ##
=======================================
  Coverage    81.7%    81.8%           
=======================================
  Files         301      301           
  Lines       70634    70614   -20     
=======================================
  Hits        57775    57775           
+ Misses      12859    12839   -20     

@ryoqun
Copy link
Member

ryoqun commented Jun 16, 2020

Thanks for working on general clean-ups!

.map_err(accountsdb_to_io_error);
if e.is_err() {
info!("{:?}", e);
continue;
Copy link
Member

@ryoqun ryoqun Jun 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ill-taste continue was a work-around introduced at: https://github.com/solana-labs/solana/pull/7281/files#diff-2099c5256db4eb5975c8834af38f6456R503

With good confidence, we no longer need this. This isn't no longer warning. It's safe to cause error and abort now as this is really bad condition now. Could you remove continue and adjust the new code so that the work-around in that dated pr will be effectively reverted?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(For the record: this workaround got deprecated at #8339)

@ryoqun ryoqun mentioned this pull request Jun 16, 2020
1 task
serialized_len,
deserialize_from(&mut stream).map_err(accountsdb_to_io_error)?,
);
let serialized_len = min(serialized_len, deserialize_from(&mut stream)?);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay! this reads a lot better. :)

Copy link
Member

@ryoqun ryoqun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Flawless and well-thought cleaning PR ever! Thanks!

@ryoqun ryoqun merged commit 50c93d4 into solana-labs:master Jun 17, 2020
@ryoqun
Copy link
Member

ryoqun commented Jun 17, 2020

@svenski123 Admitted, error handling is rough areas in our codebase. Thanks for polishing! You might find these interesting as a further direction towards better error handling:

  • It seems that there are bunch of places doing format!() or .to_string() needlessly when casting to std::io::ErrorKind::Other.
  • It seems that there are bunch of places spelling out Box<bincode::ErrorKind> which can be just said bincode::Error as you did in this pr.
  • Validator::new is chaos and it's doing process::exit because of the unproper use of ::new() -> Self convention (no Result<> here). It just needs more idiomatic rusty instantiation and break up the code...
    process::exit(1);

@svenski123
Copy link
Contributor Author

Regarding error types, I think something like https://docs.rs/anyhow/1.0.31/anyhow/ would make sense in a number of places.

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

Successfully merging this pull request may close these issues.

2 participants