Page History

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 032003|AA. Java References#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.

According to the Java API \[[API 062006|AA. Java References#API 06]\], class {{Thread}} documentation, 

It is also possible to disassemble a class, remove any declared checked exceptions and reassemble the class so that checked exceptions are thrown at runtime when this class is used \[[Roubtsov 032003|AA. Java References#Roubtsov 03]\]. Simply, compiling against a class that declares the checked exception and supplying one at runtime that doesn't, also suffices. Similarly, a different compiler than {{javac}} might handle checked exceptions differently. Yet another way to allow undeclared checked exceptions is to furtively use the {{sun.corba.Bridge}} class. All these methods are strongly discouraged.  

\[[JLS 052005|AA. Java References#JLS 05]\] Chapter 11: Exceptions
\[[Venners 032003|AA. Java References#Venners 03]\] "Scalability of Checked Exceptions"
\[[Roubtsov 032003|AA. Java References#Roubtsov 03]\]
\[[Schwarz 042004|AA. Java References#Schwarz 04]\]
\[[Goetz 04b2004b|AA. Java References#Goetz 04b]\]
\[[Bloch 082008|AA. Java References#Bloch 08]\] Item 2: "Consider a builder when faced with many constructor parameters"
\[[MITRE 092009|AA. Java References#MITRE 09]\] [CWE ID 703|http://cwe.mitre.org/data/definitions/703.html] "Failure to Handle Exceptional Conditions", [CWE ID 248|http://cwe.mitre.org/data/definitions/248.html] "Uncaught Exception"