---
title: "Comment by VH on \"Stop catching errors in TypeScript; Use the Either type to make your code predictable\" | Hashnode"
description: "Very good design pattern to handle business logic exception. Yeah, those outcomes/exceptions/errors are from business logic, they are defined by developers. But"
url: "https://hashnode.com/posts/stop-catching-errors-in-typescript-use-the-either-type-to-make-your-code-predictable/61740f980f452c1cd94fa17c/comment/662b2b76b5f9fcb5364d25c2"
---

[Discussion](https://hashnode.com/posts/stop-catching-errors-in-typescript-use-the-either-type-to-make-your-code-predictable/61740f980f452c1cd94fa17c)

Comment [Stop catching errors in TypeScript; Use the Either type to make your code predictable](https://hashnode.com/posts/stop-catching-errors-in-typescript-use-the-either-type-to-make-your-code-predictable/61740f980f452c1cd94fa17c)

[VH](https://hashnode.com/@Silverbullet069)

[Apr 26, 2024](https://hashnode.com/posts/stop-catching-errors-in-typescript-use-the-either-type-to-make-your-code-predictable/61740f980f452c1cd94fa17c/comment/662b2b76b5f9fcb5364d25c2)

Very good design pattern to handle business logic exception. Yeah, those outcomes/exceptions/errors are from business logic, they are defined by developers. But what about, errors that are thrown from 3rd-party packages?

Example:

```
import {readSync} from 'fs'
...
const json = await readSync(pathToFile)
```

and somehow there is an exception throw from `readSync` via many reason (file not found, file corruption, some process delete it, ...). How will you handle this?