In the above example, we have two versions of an application, one with "exception handling", and one without. This choice is only allowed when the exceptions are a subclass of RunTimeException. Other exceptions must be caught, otherwise the compiler will complain. For instance, an IOException is not a runtime exception. So, for every time you open a file, you must program what will happen if the operation is unsuccessful, e.g. if the file is not there or not readable. In other words, the purpose of the Exception-mechanism is to enforce correct and complete programming. However, runtime exceptions allow for some sloppiness. This will keep programming less cumbersome, but the responsability for the programmer is larger.

The rule of the thumb for handling exceptions and errors is:

1. exceptions you should catch;
2. runtime errors you should prevent;
3. errors you let go.