United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6376696 : Introduce a compiler option that turns off exception checking

Submit Date:
Updated Date:
Project Name:
Resolved Date:
Not an Issue
Affected Versions:
Fixed Versions:

Related Reports

Sub Tasks

Allow checking of exceptions as described in the JLS ????11.2.3 to be disabled.  On way of doing this could be to add a compiler option that turns all exception checking off.  Another possibility could be to only let the compiler option disable checking of a particular subclass of Exception, and then let a some of the existing exceptions in the Java API inherit from that class, for instance IOException.

The java language spec mandates that if a method A calls another method B that throws a checked exception X, either A must catch and handle X or declare that it throws X.  This is reasonable in some situations when the exception is best handled locally, for instance with InterruptedException.  But in many other situations, for instance with many IOExceptions, exceptions are best handled by a bottom level exception handler.  Checked exceptions gets in the way of this by either forcing any part of the code that touches a checked exception to declare that it might throw that exception, which often breaks encapsulation, or to handle the exception locally when it is better handled somewhere else.

One situation where this gets in your way is if you define a visitor interface for a syntax tree and it turns out that a method in some implementation of this visitor might throw a checked exception.  You then either have to declare in the interface that this method might throw the exception or handle the exception locally.  Both ways are undesirable: either all code that uses any implementation of the visitor must now deal with this exception or you are forced to handle the exception locally when it is probably better handled at a bottom level exception handler.  The latter case is especially bad because if it occurs often you are less likely to handle exceptions properly, which is in direct conflict with the rationale for introducing checked exceptions.  Another way to handle this case is to throw a chained exception which is really just a way of working around checking the exception, and which still forces you to write a boilerplate exception handler locally.

Allowing exception checking to be turned off does introduce some problems.  For instance, existing code might call a method 'm' that doesn't declare that it throws any exceptions and expect that any exception thrown from that method must be an Error or a RuntimeException.  If 'm' turns out to have been compiled without exception checking it might actually throw a checked exception anyway, which might break the existing code.  However, the same thing might happen today if the code is compiled agains a version of 'm' that doesn't throw the exception but run using a version of 'm' that does.

There are probably other compatibility issues to work out but it would save a lot of people at lot of trouble, and cause code to be easier to manage and to evolve without breaking compatibility, if it was possible to turn this checking off.



I accept that checked exceptions can add verbosity when intermediate methods merely re-throw exceptions from deeper in the call stack. I also accept that because 'throws' clauses do not affect binary compatibility, client code can get unexpected exceptions. (When, as you say, "the code is compiled agains a version of 'm' that doesn't throw the exception but run using a version of 'm' that does.")

Now, some people don't want to declare checked exceptions at all. That is their view, and there are RFEs for it. However, in most cases, declaring checked exceptions is an important part of documenting a method's semantics. Declaring checked exceptions but not actually checking at compile-time what is thrown feels like the source of many bugs to me.

Consequently, use cases against having to declare checked exceptions, and use cases which want to declare but not check checked exceptions, are not likely to make it into Java in the forseeable future.

Hardware and Software, Engineered to Work Together