Go Raw Errors and Well-Formed Errors: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 7: | Line 7: | ||
The pattern requires to represent the known edge cases as "well-formed" errors and declare them as part of our component API. When exported, errors become part of your package's public API and must be treated with as much care as you would any other part of your public API. All other errors are "raw errors" and represent bugs. | The pattern requires to represent the known edge cases as "well-formed" errors and declare them as part of our component API. When exported, errors become part of your package's public API and must be treated with as much care as you would any other part of your public API. All other errors are "raw errors" and represent bugs. | ||
<font color=darkkhaki>Further explore and document here if I find a use case.</font> |
Revision as of 23:52, 12 February 2024
External
- Concurrency in Go by Katherine Cox-Buday, Chapter 5. Concurrency At Scale, Error Propagation
Internal
Overview
This error handling pattern is built around the fact that all errors belong to one of two categories: bugs and known edge cases (disk full, network failure, etc.).
The pattern requires to represent the known edge cases as "well-formed" errors and declare them as part of our component API. When exported, errors become part of your package's public API and must be treated with as much care as you would any other part of your public API. All other errors are "raw errors" and represent bugs.
Further explore and document here if I find a use case.