From 09a9c664284c69583bce5488456c2ddda7f6f019 Mon Sep 17 00:00:00 2001 From: user Date: Wed, 20 Jul 2022 18:02:20 +0200 Subject: [PATCH] docs: updated 'Domain Errors' section --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4a65717..f6385f4 100644 --- a/README.md +++ b/README.md @@ -743,7 +743,7 @@ Exceptions are for exceptional situations. Complex domains usually have a lot of Returning an error instead of throwing explicitly shows a type of each exception that a method can return so you can handle it accordingly. It can make an error handling and tracing easier. -To help with that you can create an [Algebraic Data Types (ADT)](https://en.wikipedia.org/wiki/Algebraic_data_type) for your errors and use some kind of Result object type with a Success or a Failure condition (a [monad]() like [Either](https://typelevel.org/cats/datatypes/either.html) from functional languages similar to Haskell or Scala). Unlike throwing exceptions, this approach allows to define types (ADTs) for every error and will let you see and handle those cases explicitly instead of having invisible exceptions and using `try/catch`. For example: +To help with that you can create an [Algebraic Data Types (ADT)](https://en.wikipedia.org/wiki/Algebraic_data_type) for your errors and use some kind of Result object type with a Success or a Failure condition (a [monad]() like [Either](https://typelevel.org/cats/datatypes/either.html) from functional languages similar to Haskell or Scala). Unlike throwing exceptions, this approach allows defining types (ADTs) for every error and will let you see and handle them explicitly instead of using `try/catch` and having exceptions that are invisible at compile time. For example: ```typescript // User errors: