Handling errors as domain concepts

In most programming projects, there's confusion as to how and where errors should be handled.

Errors account of a large portion of our application's possible states, and more often than not, it's one of the last things considered.

When we encounter some code that will probably result in a non-optimal state, we often ask ourselves questions like:

  • Do I throw an error and let the client figure out how to handle it?
  • Do I return null?

Howdy 👋

This is an online wiki and book about the basics of software design and architecture with TypeScript by Khalil Stemmler, Developer Advocate @ Apollo GraphQL .

This book’s mission is to teach developers the essential skills and practices to write testable, flexible, and maintainable code.

You can read more about the learning journey in the "Software Design and Architecture Roadmap 🖼️".

Already bought it?

If you’ve already purchased the book, click here to re-send your link. You can read the online wiki or download a copy of the book in PDF, EPUB, and Kindle versions.

Want access?

You can read the intro to the book for free and visit solidbook.io to buy the book/wiki (it's currently on pre-sale for 33% off)! For recent updates, click here. To get an idea of my writing, read some of my best free content here and here.

Need help?

Something not working? Have a question? You can reach me on Twitter or khalil@khalilstemmler.com.