> Don't rethrow the same exception. Handle it. It you want to handle it by throwing another internal unchecked exception, that's fine-

No, that's not fine. Typically, the layer immediately wrapping the throwing code has no knowledge about semantics. It's measurement code, logging code, caching code, transaction handling code, batch explode/aggregation code etc, but nothing that could make sense of a FileNotFoundException. The layer that wraps all this infrastructure code has more info, and can make sense of individual exceptions. By wrapping the original exception, this code now has to go on a getCause() safari to find out what happened. And yes, with checked exceptions there is no way around that, and that's the reason they should go.

I don't mean to wrap it in a generic exception, I mean to wrap it in a context-specific exception written for the purpose. A "UserDoesntExistException", or a "DatabaseNotRespondingException". Something for the purpose that likely exists in a useful hierarchy.

This is better, but it could have been the original exception all along, given the rare number of cases in real-world code where the call site actually knows how to recover.

Typically you don't need to catch at this level of granularity. A generic UnavailableException would cover it. The reasons why a method can fail vary by implementation and you typically don't need to expose this at the API level. It shouldn't be a breaking change for a method to fail for a different reason because the implementation changed.

If you take this approach, there are two kinds of methods: those that always succeed and those that can fail. It's similar to how Go's error type works.

Java is a mess not due to the existence of checked exceptions, but because they created an unfortunate exception hierarchy and that resulted in inconsistent API design where there's no consensus about what to do.

This is exactly the opposite recommendation I give.

Never handle an exception (always rethrow) unless you know that you can do something specific in that exceptional case. In most cases just rethrowing the exception is the correct thing, and many bugs come from people mishandling exceptions.

A perfect example is InterruptedException, where really bad things happen if you don’t rethrow that.

Just rethrow, it’s generally the best thing.

I think you both generally agree. The choice is either handle now, or rethrow and handle later.

Which one is "default" depends on if you're writing library code, application code, or service code. Especially in services rethrow, catch all at the top, and log is common and makes sense.

Probably less appropriate for a zlib or a file not found call. You'll have to do something (unless the answer is crash ... Which it is a sometimes!)

Ultimately, the thing I most disagree with in the GP is the idea of handling and rewrapping. There a many cases where this would be bad practice.

It just depends I suppose? Sometimes you rewrap to get an unchecked runtime exception out of it. Sometimes there's context worth adding: new IndexLoadException(ioException, "Is Hadoop down?").

Either way I think the one thing I hate hate hate is, losing stacktraces! Don't throw a new exception without wrapping the old one. I need that info!

> Either way I think the one thing I hate hate hate is, losing stacktraces! Don't throw a new exception without wrapping the old one. I need that info!

This! Throw as many RuntimeExceptions as you like, so long as you include the originating exception.

Again I go back to InterruptedException, this advice is very wrong in that context, and similarly others.

People often make the very big mistake of generically catching Throwable and then rewrapping that, which would include all Error types. Those should must be rethrown without wrapping. I don’t think you meant to imply that, but it’s easy to overapply advice like this.

I think the problem is that checked exceptions seem to defeat the benefits of using exceptions.

You're better off returning something like Rust's Result type.

They are completely equivalent.

They aren't, because you have to use clunky verbose syntax (and try/catch blocks aren't expressions, which makes things worse). Also, there are several limitations on generics with exceptions that don't exist with regular values.

My point is that there's no reason to include special syntax/concepts for checked exceptions over just using values.

I quite prefer the Option monad approach in Scala where you can pattern match the result. Far more succinct and doesn't require program logic flow to be interrupted.

Thing is - the person who wrote that code doesn't know what I'm doing with it - a recent offending library for me was Jackson throwing an IOException if it can't parse the JSON.

Except I knew that it would always be receiving valid JSON because this code was downstream of a Kafka Streaming app whose entire purpose was to validate that the record was valid JSON that conformed to a JSON schema.

But the authors of Jackson require me to add a useless catch clause to my code. And seriously, an IOException for unparseable JSON? At least throw an UnparseableJsonException or something.

I will write catch clauses for exceptions that could reasonably be expected to occur and are recoverable from - but if an exception does occur, and you can't recover from it, what the hell is the point of a mandatory catch, log, and rethrow?

In my experience, 99% of the handling of a checked exception is to catch them, and rethrow in RuntimeException, which shows that the intent doesn't match the reality of how people are programming.

But, that said, I'm writing code on the JVM for our own internal apps - we're never going to have a desktop user facing a stack-trace. I think that when Java was developed it was intended to be far more user-facing than it is now.

I agree that checked exceptions enforce clarity however I absolutely disagree on the fact that the exception should be managed immediatly. Usually exceptions can and must be managed at different levels of the call stack depending on their origin and destination. My experience tells that usually in an application there are just a few sinks that can be used to ultimately manage exceptions raised from different application flows. The pro of checked exception is to enforce exception management the cons is that they require a pedantic management. For unchecked exceptions pros and cons are exactly inverted. What would be ideal is to have a meta-exception management rule system that would allow to specify which exceptions are allowed to pop-up and which must be managed at the class and method level. Is there any language that provides something nearly similar to this?

It really comes down to two things:

1. How exceptional are exceptions?

2. Are committed to providing good language support?

If exceptions are the result of programmer error or terrible malfunction, then unchecked exceptions are fine. But in Java, exceptions are fairly common, even for common low-level stuff: read a non-existent file, parse a non-numeric string, look up a non-existent domain name. If you're going with that approach, it makes sense to type and control these.

As for language support...Java is interesting. It doesn't have unions in any of its types except for exceptions. But that makes it interesting trying to write generics, e.g. in a very functional approach. In my experience, most functional Java paradigms just don't support any user of checked exceptions and you make all exceptions unchecked.

The trouble is they don't scale and are generally just a pain. Especially with how bad they play with lambda expressions.