Following on from the example of todo methods in SmalltalkLanguage, I think I like this JavaIdiom:
final public class UnhandledException extends ChainedRuntimeException? { public UnhandledException(String msg, Throwable cause) { super(msg, cause); printWarning(); }The general idea is that first-cut code can look like thisprivate void printWarning() { PrintStream? err = System.err; err.println("FIXME: Unhandled checked exception: " + this.getMessage()); this.getCause().printStackTrace(err); } }
try { // do some file operations } catch (IOException e) { throw new UnhandledException(e); }and then be refactored to handle the checked exception properly, possibly by ConvertExceptions. It's important that people do eventually get around to handling it at an appropriate level of abstraction, and so this makes sure that unhandled exceptions will be noted and acted on at the right time.
The QCI Java Utils library (http://www.qlue.com/downloads/) uses this. In the com.qlue.util.assert package, there is an exception called UnexpectedExceptionException?. The general idea is that in your first couple of passes, your code is littered with asserts and UnexpectedExceptionExceptions? to make sure that you don't forget about error scenarios. In later passes, you connect up error handling code and refactor as necessary.
The common: } catch (SomeException? e) {} idiom (known as the EmptyCatchClause) is extremely dangerous and makes debugging very difficult when the error actually does happen.
At first I was wondering why you didn't just throw a RuntimeException instead. The key seems to be that the exception is logged by the exception constructor, so if the UnhandledException is itself suppressed further up the call chain (perhaps by a catch-all for Exception), a warning is still reported. (Perhaps there are other situations where a LoggedException? would make sense?)
This page mirrored in JavaIdioms as of April 29, 2006