Why Do Some Developers Oppose Checked Exceptions in Java?

Objection to checked exception

For years I have been unable to get a decent reply to the question: Why are some developers so opposed to checked abnormal? I've had multiple conversations, read blog posts, and read Bruce Eckel's perspective (he's the first person I've ever seen speak out against this).

I'm currently writing some new code and am very careful about how I handle exceptions. I'm trying to understand the "we don't like checked exceptions" crowd's perspective, but I still can't get it.

Every conversation I've had has ended with the same question without an answer... Let me set this up:

Generally speaking (by the design of Java),

• Error is used for things that should never be caught (the VM is allergic to peanuts and someone poured a jar of peanuts over it)
• RuntimeException is used for things the programmer did wrong (the programmer walked out of the array end)
• Exception (except RuntimeException) is used for things outside the programmer's control (the disk is full while writing to the file system, the process's file handle limit has been reached, no more files can be opened)
• Throwable is just the parent class of all exception types.

A statement I often hear is that if an exception occurs, all the developer can do is exit the program.

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

As for the "I just quit" argument, what I'm saying is that even if you quit, you need to show a reasonable error message. If you just avoid handling errors, your users won't be too happy when the program quits without a clear indication of why.

For the "it makes refactoring difficult" crowd, this suggests that the appropriate level of abstraction was not chosen. Instead of declaring that a method throws an IOException, the IOException should be converted into an exception that is more appropriate for what is happening.

I have no problem wrapping Main with catch(Exception) (or in some cases catch(Throwable) to ensure the program exits gracefully - but I always catch the specific exception I need to catch. This way Do at least allow me to display a proper error message

The question people never answer is this:

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

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

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

If the answer is that you only catch exceptions that you know are thrown, then how do you know which exceptions are thrown when programmer X throws a new one? What happens when you throw an exception and forget to catch it? That seems dangerous to me

.

I would say that the program showing 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? And answer that unanswered question?

I'm not looking for advice on using either model, I'm looking for the reasons why people extend from RuntimeException instead of from Exception, and why they catch the exception and then rethrow one Instead of adding a RuntimeException throw to their methods. I'd like to understand the motivation for not liking checked exceptions.

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