Agree with that. Exceptions suck, try-catch is an infamy, and errors not in the signatures or exploitable in any way by Typescript is a living nightmare. But what I hate even more is multiple ways to handle errors.

You sound like, living in a car society is a nightmare because you can't dodge cars that run into you.

Hopefully there's an ideal world for you.

> living in a car society is a nightmare

More like living in a society with invisible cars. You only know there was a car when it hits you. And every time you move a foot you have to first try to throw a pebble to check if there's a car

The thing is not using try/catch, like the first case, sometimes you don't know if a function will throw or not. You can't tell from the function signature as well.

So this provides a way that told you the function you called might throw. It's more like an alert before a crash.

[res, err] is good, actually I used this style for a long time. `unwrapit` is a nicer way to let you write [res, err], like type hints and other utility methods.

Because errors have different semantics. Some should kill your whole app and propagate up to the top layer, where a transaction that wraps the whole http request will be cancelled, or a error screen will be shown to the user. But other errors are part of business as usual — they should be handled explicitly, and type system should force you to do it and match the right exception type.

Personally though I would go with fp-ts.