I've just been reworking some
JavaLanguage code that ignores checked exceptions when it doesn't know what to do. This is a hard problem in Java in general: at the time you're writing, you may not know how you want to handle it, but your program won't even compile until you do something. So, programmers tend to have ad-hoc solutions.
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();
}
private void printWarning() {
PrintStream err = System.err;
err.println("FIXME: Unhandled checked exception: " +
this.getMessage());
this.getCause().printStackTrace(err);
}
}
The general idea is that first-cut code can look like this
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.
--
MartinPool
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.
--
EricVought
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?)
--
BrianSlesinsky
CategoryException