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

Prevent using .unwrap() and .expect() in codebase #41

Open
2 tasks
pan93412 opened this issue Aug 1, 2022 · 1 comment
Open
2 tasks

Prevent using .unwrap() and .expect() in codebase #41

pan93412 opened this issue Aug 1, 2022 · 1 comment

Comments

@pan93412
Copy link
Collaborator

pan93412 commented Aug 1, 2022

Abstract

crypto-crawler panics when the data format is invalid, which may have better recoverable way to indicate instead of just aborting the whole tasks.

Solution

Replace all of them to Result<T, SimpleError>:

ws_msg.data.B.parse::<f64>().map_err(|_| SimpleError::new("Failed to parse ws_msg.data.B"));

Besides, I recommended replacing SimpleError to anyhow. It allows us wrapping all the error with a generic Error:

fn parse() -> anyhow::Result<T> {
  // Even simpler than `.unwrap()`. Besides, the `parse()` is recoverable now!
  ws_msg.data.B.parse::<f64>()?;

  // If you need context:
  ws_msg.data.B.parse::<f64>().context("Failed to parse ws_msg.data.B")?;
}

TBDs (To Be Discussed)

  • Use anyhow or remain SimpleError? I prefer former.
  • Migrate it with less breaking changes (or just make it without writing too many “runtime” to unwrap)
@soulmachine
Copy link
Collaborator

Ideally there should be zero unwrap() in code, but it is very difficult to eliminate all unwrap().

I'll look into this issue and decide next step soon.

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

2 participants