Page History

It is mandatory to handle checked exceptions in Java. The compiler enforces this rule by ensuring that every possible checked exception is either declared using the throws clause or handled Java requires that each method must address every checked exception that can be thrown during its execution either by handling the exception within a try-catch block . Unfortunately, this guarantee does not carry over to the JVM runtime environment, preventing the caller from determining which exceptions the callee can throw. Checked exceptions provide a checklist of unusual events that can be handled during program execution whereas unchecked exceptions involve programming mistakes that should be caught early, without expecting the Java runtime to stage a recovery. Undeclared checked exceptions resemble the latter in behavior as the compiler does not force the programmer to handle themor by declaring that the exception can propagate out of the method (via the throws clause). Unfortunately, undeclared checked exceptions can be thrown at runtime. Consequently, callers cannot statically determine the complete set of checked exceptions that could propagate from an invoked method.

A common argument favoring undeclared checked exceptions (even unchecked exceptions) is that the caller does not have to define innumerable {{catch}} blocks for each specific checked exception that the callee can throw. Likewise, handling each exception within the callee is believed to clutter-up the code. One way to deal with this issue is to wrap the specific exceptions into a new exception, appropriate for the abstraction level. For example, a method may throw an {{IOException}} instead of specific exceptions such as {{FileNotFoundException}}. While exception handling should be as specific as possible, a compromise can be struck this way, to increase the code readability in complex systems \[[Venners 2003|AA. Bibliography#Venners 03]\]. However, wrapping checked exceptions into a broader exception class may not provide enough context for a recovery at the top level. Unchecked exceptions and undeclared checked exceptions, on the other hand, help reduce clutter in code but are unsuitable when a client is expected to recover from an exceptional condition.

Clients or callers are expected to know the exceptions that the underlying code can throw. For this reason, developers must sufficiently document all possible unchecked and undeclared checked exceptions. Undeclared checked exceptions need diligent documentation. Security critical software should must make this contract explicit. Yet another difficulty in dealing with undeclared checked exceptions is that sensitive exceptions cannot be sanitized before delivery, in the absence of a dedicated exception reporter. For these reasons, undeclared checked exceptions should be avoided.

...