I agree but I think was also because Java didn't have sum types (or still doesn't? years I haven't read Java) and rethrowing is super easy, while Rust kinda nudges you into the right direction (if you need to rethrow at all, think if you want to rethrow verbatim or wrap with a semantic error type).

Right idea at the wrong time.

yep, 90% ergonomics in my view. If it had its time again with modern ergonomics thing could look very different.

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.

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.

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

Go doesn't require you to handle it at all. Rust made the right compromise with !

> 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.

They were overused, but some actually make sense, such as the IOException and SQLException

The problem with them all always comes when the ever-steady march of abstractions, features, and edge cases results in one routine throwing the same two error classes but in different places, and how you handle them is different despite being the same wrapper. Add a thousand developers and several years of churn, and poof you get extremely complex bugs that result from errors seeming to come from one place, but actually coming from another.

Having been on the receiving end of debugging that a few times, I no longer mind the in-band error handling, although admittedly I'm inexperienced enough to be confident its better. Just for the random code I've had to read where I just need to know exactly how something I didn't write and will never read again works, and whether the error is handled and how, i love reading in-band error handling, even if I too dislike the way an error laden routine must be written. Over time I've come to appreciate elegance "in the large" as opposed to the code I see in any individual function.

[delayed]

In the vast majority of programs, errors and non-results are irrelevant at the call site. You want to program for the happy path and not wrap every single call with error checking code or `try/catch/finally`.

    h = file_open(path)
    data = file_read(h)
    file_close(h)
    return data

is the code you want to read. This essentially is:

    return file_open(path).success(h -> h, file_read(h)).success(h, data -> file_close(h); data)

A language with thoughtful error handling primitives will support such code.

that is the same as saying the method throws IOException

It might throw one. There is a difference between documenting what exceptions can be thrown and forcing every consumer to handle them.

returning a non-success you either handle it or pass it up the chain, potentially with not a lot of information about what originally caused it. with an exception you can retain the full information about what happened by either rethrowing it, throwing your own exception with it embedded as the cause or declaring that you don't handle it by saying you can throw it.

I generally prefer exceptions to result codes. You can even use the mechanism to throw useful results across nested function calls.

I do prefer Maybe/Option/Either style returns in some cases though. Makes for a cleaner API.

So each method has its uses.

I also have this nuanced view. I am glad my hashmaps don't throw KeyNotFoundException.

Eh, it's weird. You usually don't care exactly what type of exception is thrown. If you do, usually you only care about that one type and the rest fall into the "unexpected error" category. HTTP did this well with 4xx being client's fault and 5xx being server's fault.

IOException must be #1 on the list of most ignored exceptions. Like okay what am I supposed to do really I'm just trying to run a select against my db

Well, for example, if you had opened a file to put the data into, you might delete the file or restore from a backup. But even if the answer is nothing, bubbling it all the way up to main is not the wrong answer. The point isn't whether you can do something, it's whether someone can do something.

> You want to program for the happy path

This is the root of a lot of the evil. Yes, humans want to program for the happy path. It is a lot more fun. However, that bias leads to so much lack of diligence to properly deal with the unhappy path.

Syntax is not going to solve logic errors. No amount of checked exceptions or forced unwrapping of a result will help with TOCTOU or any number of similar vulnerabilities in code.

You ideally want to attack the problem at two ends:

- make the syntax noise-free so you can see what is happening

- build primitives at the syscall and stdlib level for common footguns

You would still need to deal with domain-specific logic errors, but you have at least reduced the surface area exposed to casual attacks.

People using exceptions want to handle the unhappy path, just usually not at the call site.

> This is the root of a lot of the evil

It is not. Being extremely restrictive in the happy path, throwing all over the place, but have generic error handling code at the top level (e.g. HTTP entry point) makes for some pretty robust, stable, easy to read software. Albeit it typically has somewhat rough user experience.

The thing is, that's a pretty good place to start. From there on, you can handle exceptions one by one, surgically, and make things nicer.

I keep hearing how diligent it is to handle errors at the call site, always by people who end up making services that either crash for preventable reasons or bury errors.

I always thought the ideas was great, but type system was holding it back. If you could have expressed that your thrown exceptions are the same as some other method's (e.g. a method of a class given as a parameter), and some other classes, then it could have been a lot less annoying. Powerful, even! But Java did take its sweet time to get even type parameters.

I have written very little Java, though, so this is more of an armchair analyst position.

Better design breeds better habits. In Java, you can end up handling a DNS exception 20 layers up the stack, even if your call never actually triggers a DNS lookup, simply because some method deep in the call stack declares it as possible. The culture is to propagate or wrap exceptions rather than translate them into domain-specific errors near the source.

Rust makes handling and mapping `Result` locally more ergonomic, even though `?` makes propagation easy too. Rust, however, also makes it easy to lose the context during propagation and end up with useless `Error`.