Hacker News new | past | comments | ask | show | jobs | submit login

This looks like it'd be a massive pain to debug unexpected exceptions in the middle of a chain. Would you have to decompose the entire thing and step in and out of every step? Yuck.

You should never have unexpected exceptions if you embrace static typing and one of the many libraries that take this idea and do it better, for example `purify-ts`. It also comes with methods included for statements that might throw such as `JSON.parse`.

What if you miss one of these exceptions?

The entire purpose of this school of error handling is that there are no exceptions ever and unhandled errors are compiler errors.

It's weird in JS since exceptions to exist and you end up needing to build a library of primitives that swallow exceptions and return them as errors. I wouldn't do this in JS without tooling support because it's possible to miss them but in principle the case you describe should never be able to happen and that guarantee is enforced at the language level.

So essentially Java checked exceptions but which also applies to descendants of RuntimeException?

Yes! Personally I would argue a that this can end up being a little better in practice since errors don't interrupt your program's flow and there's not an implicit `if err jump` attached to every line but I suppose that's stylistic preference.

It’s all nice and easy, but how would you handle OOMs in that scenario?

Or the cases with Rust’s assertions which kill the program?

The chance you’d need to rebuild a huge amount of software for that.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact