-
Notifications
You must be signed in to change notification settings - Fork 138
Error Wrapping Best Practices
Traun Leyden edited this page Nov 20, 2017
·
3 revisions
- Wrap things at the library boundary rather than internally within the codebase -- for example, a call out to GoCB. This should avoid double-wrapping.
- Always use
Cause()
when comparing error types/values, eg changeif err == couchbase.UpdateCancel
->if Cause(err) == couchbase.UpdateCancel
. - When wrapping an error, beware that it is a risky operation that can break code that compares errors types or values. Look at callers and make sure they are calling
Cause()
. - Avoid wrapping any errors in any performance critical path due to the performance hit from grabbing the stack frames.
- Avoid double-wrapping for performance hit reasons, as well as stack clarity. However there are some exceptions:
- In certain cases when a higher-up stack frame can add valuable context
- When the error is known to be a fatal error