https://github.com/coderbyheart/do-not-throw-errors
Tech talk on why not to throw errors
https://github.com/coderbyheart/do-not-throw-errors
Last synced: 8 months ago
JSON representation
Tech talk on why not to throw errors
- Host: GitHub
- URL: https://github.com/coderbyheart/do-not-throw-errors
- Owner: coderbyheart
- Created: 2023-09-11T12:15:37.000Z (almost 3 years ago)
- Default Branch: saga
- Last Pushed: 2023-09-11T12:24:18.000Z (almost 3 years ago)
- Last Synced: 2025-02-01T11:11:31.767Z (over 1 year ago)
- Language: TypeScript
- Size: 1.95 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
In the tech talk I've discussed the advantages of returning error objects instead of using exception handling in code. Here are the key points from the conversation:
- using exceptions has downsides, such as not explicitly documenting error behavior in the API and needing to handle exceptions at various levels of code.
- TypeScript doesn't fully address error handling documentation.
- Instead, return error objects instead of throwing exceptions.
- The benefits of this approach include not killing the process on error, providing a clear API documentation, and enabling IDE autocompletion for error handling.
- The speaker emphasizes that returning error objects makes it explicit in the code that errors may occur and allows for better error message customization.
- They mention the use of [descriptive error objects following REST API recommendations](https://datatracker.ietf.org/doc/rfc9457/).
- The [railway-based programming principle](https://blog.logrocket.com/what-is-railway-oriented-programming/) is introduced, which shifts error handling responsibility to the calling code.
The speaker encourages the adoption of this error handling pattern for its advantages.
In summary, the talk discusses the benefits of returning error objects over using exceptions in code to improve error handling and documentation. This approach helps make error handling more explicit and flexible.