[randomdev3]

Why make it complicated? The language supports catching errors, use that. You may not like it but that's the thing you have. Of course you can wrap errors, return [response,error] or whatever in your implementation of api calls etc. but you don't need third-party libraries for that.

[musicq]

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.

[golergka]

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.

[thiht]

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.

[mekster]

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.

[thiht]

> 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