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

Better error handling #39

Open
KyrietS opened this issue Dec 14, 2021 · 1 comment
Open

Better error handling #39

KyrietS opened this issue Dec 14, 2021 · 1 comment
Labels
feature New feature or request improvement Code refactor or minor changes that are not new features

Comments

@KyrietS
Copy link
Owner

KyrietS commented Dec 14, 2021

Many functions in this project simply return Result<()>. Sometimes it's Result<Something, String> to pass some text error message. There are no custom Result classes whatsoever. A complete redesign of error handling is necessary to proceed with new features.

Key points for new error handling system:

  • generalized - there should be one major error type
  • extensible - it should be easy to add new error types
  • descriptive - error should be able to contain string message, maybe some error code (but not necessarily)
@KyrietS KyrietS added feature New feature or request improvement Code refactor or minor changes that are not new features labels Dec 14, 2021
@KyrietS KyrietS added this to the Managing snapshots milestone Dec 14, 2021
@KyrietS
Copy link
Owner Author

KyrietS commented Dec 19, 2021

Idea: instead of Result<Something, String> it's better to do Result<Something, MyErrorEnumType> where MyErrorEnumType can also store a string if it's necessary. I could not only print every error as always but also match them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request improvement Code refactor or minor changes that are not new features
Projects
None yet
Development

No branches or pull requests

1 participant