Go Raw Errors and Well-Formed Errors: Difference between revisions
Jump to navigation
Jump to search
(Created page with "=Internal= * Go Error Handling") |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | |||
* Concurrency in Go by Katherine Cox-Buday, Chapter 5. "Concurrency At Scale", Section "Error Propagation" | |||
=Internal= | =Internal= | ||
* [[Go_Language_Error_Handling# | * [[Go_Language_Error_Handling#Raw_Errors_and_Well-Formed_Errors|Go Error Handling]] | ||
=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 package-exported. When declared as such, errors '''become''' part of the package's public API and must be treated with as much care as any other part of the public API would be treated. This applies to both typed errors and "sentinel" errors. All other errors are "raw errors" and represent bugs. | |||
<font color=darkkhaki>Further explore and document here if I find a use case.</font> | |||
Latest revision as of 15:23, 14 May 2024
External
- Concurrency in Go by Katherine Cox-Buday, Chapter 5. "Concurrency At Scale", Section "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 package-exported. When declared as such, errors become part of the package's public API and must be treated with as much care as any other part of the public API would be treated. This applies to both typed errors and "sentinel" errors. All other errors are "raw errors" and represent bugs.
Further explore and document here if I find a use case.