Hacker News new | ask | show | jobs
by ivanjermakov 427 days ago
Errors as values approach suffers similar problem as async/await - it's leaky. Once the function is altered to possibly return an error, its signature changes and every caller needs to be updated (potentially all the way to the main(), if error is not handled before that).

This approach is great when:

* program requirements are clear

* correctness is more important than prototyping speed, because every error has to be handled

* no need for concise stack trace, which would require additional layer above simple tuples

* language itself has a great support for binding and mapping values, e.g. first class monads or a bind operator

Good job by the author on acknowledging that this error handling approach is not a solver bullet and has tradeoffs.

1 comments

It’s only leaky if you do not consider failure cases to be as equally intrinsic to an interface’s definition as its happy-path return value :-)