Why Do Developers Oppose Checked Exceptions in Java?

Against checked exceptions

For many years, I couldn't get a satisfactory answer to the following question: Why are some developers so opposed to checked exceptions? I had many conversations, read blog posts, and read the opinions of Bruce Eckel (who was the first person to speak out against checked exceptions).

I'm currently writing some new code and am paying a lot of attention to how exceptions are handled. I'm trying to understand the perspective of the "we don't like checked exceptions" crowd, but I still can't get it.

Every conversation I've ever had has ended up with the same unresolved question... Let me elaborate:

In general (by the design of Java),

• Errors are for things that should never be caught (VM Allergic to peanuts, someone accidentally sprinkled a can of peanuts on it)
• Runtime exceptions are for things the programmer did wrong (programmer went out of bounds using an array)
• Exceptions (running Except for exceptions) Yes Used for things beyond the programmer's control (the disk is full while writing a file in the file system, the process's limit on the number of file handles has been reached, the file can no longer be opened)
• The throwable object is just the parent of all exception types kind.

An argument I often hear is that if an exception occurs, all the developer has to do is exit the program.

Another common argument I hear is that checked exceptions make it harder to refactor code.

For the "I'll quit" argument, you still need to display a sensible error message even if you quit. If you just procrastinate on error handling, your users won't be too happy when the program exits without a clear reason for exiting.

For the "it makes refactoring difficult" crowd, this indicates that the appropriate level of abstraction was not chosen. Rather than declaring a method to throw an IOException, the IOException should be converted into an exception that is more appropriate for what is going on.

I don't get crazy about wrapping Main's catch(Exception) (or in some cases catch(Throwable), which ensures the program exits gracefully, but I always catch the specific ones I need Exception. Doing this allows me to at least display a proper error message

The question people never answer is:

If you throw a RuntimeException
subclass instead of an Exception
subclass, how do you know what
should catch?

If the answer is to catch Exception, then you are still handling programmer errors in the same way as system exceptions. That seems wrong to me.

If you catch Throwable, you are still handling system exceptions and VM errors (and similar errors) in the same way. That seems wrong to me.

If the answer is to only catch exceptions that you know are thrown, then how do you know which exceptions were thrown? What happens when programmer X throws a new exception and forgets to catch it? In my opinion, this is dangerous.

I would say that the message that would show the stack trace is wrong. Don't people who don't like checked exceptions think so?

So, if you don't like checked exceptions, can you explain why not, and please answer the unanswered question.

I'm not looking for advice on when to use either model, I'm looking for why people extend from RuntimeException but not from Exception, and/ Or the reason why they rethrow the RuntimeException after catching the exception instead of adding throws to the method. I'd like to understand people's motivations for not liking checked exceptions.

The above is the detailed content of Why Do Developers Oppose Checked Exceptions in Java?. For more information, please follow other related articles on the PHP Chinese website!