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

For true errors like that, I agree with you, but the parent is basically saying both "fuck monads" and "only handle errors in your top level modules".

I do think theres a 'tiering' that needs to happen for robust error handling, and I suspect you both agree more than disagree. Take the Go-ish handle everything at a lowest level vs. a Java-y handle everything at the top entry points (the parent's post exaggerated for effect) as two points for comparison.

Disclaimer: This is a variant of my Java Exceptions vs. Go err conversations. I'm working Either into it.

The Go-like approach can often force you to handle errors at the lowest level. You often have details of the error but you're without context of the program. An example is a zlib library; you don't want to handle the failure of any particular `file.read(buff)` call but rather just fail at a higher level `unzip_file(src, dest)`, and with context make choices in the program from there.

Now you can do this in Go as well, you just manually unwind returning err to the level above. It's verbose compared to exceptions (but more explicit...ish). I suspect most programs will end up resolving things at about the same level.

That's the thing with Either(), since it's doing the catching you clearly have exceptions to work with too. In terms of error handling the interesting bit is what 'tier' you handle things at, the Either vs Try/Catch are like 80% the same.

Putting a catch-all at the root doesn’t keep you from catching exceptions before they get there.

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