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

Continue improving error handling #323

Open
fredbi opened this issue Dec 7, 2019 · 0 comments
Open

Continue improving error handling #323

fredbi opened this issue Dec 7, 2019 · 0 comments
Assignees

Comments

@fredbi
Copy link
Contributor

fredbi commented Dec 7, 2019

Follow up PR #320

pkg (storage, core): wrap underlying API errors and process well-known error statuses
CLI: add more detailed guidance on well-known errors (e.g. invalid bucket, unknown context)

NOTE: if we all agree on the idea behind this PR (which starts levering my previous error wrapper), I'll start generalizing error wrapping in packages. Step-by-step CLI testing shall also drive toward more "extra guidance"-like handling.

this is okay..

.. i'd feel more convinced about the utility of error typing if there were handling toward recovery of errors rather than using the additional type information to assist in user-readable string building. i've still yet to be burned by fmt.Sprintf and errors.New or even the useful fmt.Errorf in order to build human-readable error messages.

tbth, confusing human-readable text with data interpreted by the program (i find programs easier to reason about if strings are one or the other) as in the sentinel error function gives some pause also. as i've said with the various changes re. error handling: i'm skeptical but willing to see where this path takes the codebase.

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

No branches or pull requests

1 participant