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.
Follow up PR #320
.. 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.