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

Prefer the method {{Constructor.newInstance()}} over {{Class.newInstance()}}. An alternative is to use the builder interface recommended by Bloch \[[Bloch 2008|AA. JavaBibliography#Bloch References#Bloch 08]\]. 

According to the Java API \[[API 2006|AA. Java References#APIBibliography#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 2003|AA. Java References#RoubtsovBibliography#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 2005|AA. JavaBibliography#JLS References#JLS 05]\] Chapter 11: Exceptions
\[[Venners 2003|AA. Java References#VennersBibliography#Venners 03]\] "Scalability of Checked Exceptions"
\[[Roubtsov 2003|AA. JavaBibliography#Roubtsov References#Roubtsov 03]\]
\[[Schwarz 2004|AA. JavaBibliography#Schwarz References#Schwarz 04]\]
\[[Goetz 2004b|AA. Java References#GoetzBibliography#Goetz 04b]\]
\[[Bloch 2008|AA. JavaBibliography#Bloch References#Bloch 08]\] Item 2: "Consider a builder when faced with many constructor parameters"
\[[MITRE 2009|AA. Java References#MITREBibliography#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"