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