Hacker News Reader

The question is _where_ the error needs to be handled. It's almost never directly at the call site. And then there's a few issues with checked exceptions and Java language things (RMI, closures, etc) which make checked exceptions cumbersome. An exception (checked or not) might be worse than sum types, but they're still a thousand times better then returning an error in-band.

View on HN

> The question is _where_ the error needs to be handled. It's almost never directly at the call site.

Which is why exceptions in Java can bubble up the stack? You don't have to catch it in a particular method you can let it go to the caller of the method, and so on.

Checked exceptions must be handled or declared. You end up with everything saying it can throw several random things like IOException.

Rust and Go literally have you handle it at the call site by default and if you don't want to you have to pass it on.

Go doesn't require you to handle or pass an error upwards. You can call something that returns err and just ignore it, compiler won't care. The "if err != nil" thing is annoying too. Rust made the right compromise with !

Which (at least the way it was done in Go) is ignoring 20 years of experience in programming language design.

Reply on news.ycombinator.com