Exception handling

Exception handling in the Java language complicates control-flow. Operations (such as division, possibly by zero) may implicitly throw exceptions that radically redirect the flow of control. To facilitate analysis, exception handling and its associated control-flow is made explicit in the intermediate representation. For example, null pointer and array bounds checks are inserted before object and array references, and division by zero is explicitly checked before every division operation. These explicit and comprehensive checks are intended to be targeted by aggressive optimizations designed to removed those cases with are redundant, impossible, or otherwise unnecessary. The design goal of the IR is that no statement should throw an implicit exception under any circumstance. Pursuing that goal involves changing the semantics of method invocation slightly: so that the call statement not throw an implicit exception, the IR call has been defined to return two values. In addition to the conventional (and optional) method return value, an ``exception return value'' is defined to hold the exception thrown by a method, or null if the method completed without throwing an exception. Explicit tests of the exception return value can then be added after the call statement, and control-flow made explicit as with the other IR operations. The throw statement in the IR is thus stripped of its special meaning and becomes simply an alternate return statement for the exception return value.²