Go Raw Errors and Well-Formed Errors: Difference between revisions
Jump to navigation
Jump to search
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | =External= | ||
* Concurrency in Go by Katherine Cox-Buday, Chapter 5. Concurrency At Scale, Error Propagation | * Concurrency in Go by Katherine Cox-Buday, Chapter 5. "Concurrency At Scale", Section "Error Propagation" | ||
=Internal= | =Internal= | ||
* [[Go_Language_Error_Handling#Raw_Errors_and_Well-Formed_Errors|Go Error Handling]] | * [[Go_Language_Error_Handling#Raw_Errors_and_Well-Formed_Errors|Go Error Handling]] | ||
| Line 6: | Line 7: | ||
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.). | 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 | 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. All other errors are "raw errors" and represent bugs. | ||
<font color=darkkhaki>Further explore and document here if I find a use case.</font> | <font color=darkkhaki>Further explore and document here if I find a use case.</font> | ||
Revision as of 00:03, 13 February 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. All other errors are "raw errors" and represent bugs.
Further explore and document here if I find a use case.