MOPping up Exceptions S. E. Mitchell, A. Burns and A. J. Wellings, Department of Computer Science, University of York, UK Abstract: This paper describes the development of a model for the reflective treatment of both application and environmentally sourced exceptions. We show how a variety of exception models can be implemented using an exception handler at the metalevel. The approach described allows for better separation of exceptional and normal error-free program code producing systems that are easier to understand and therefore maintain. Keywords: metalevel architecture, reflection, exceptions. 1 Introduction with particular emphasis on the relationship between concurrency and reflective The principle reason for the inclusion of exceptions. Finally, we evaluate the exception handling mechanisms in effectiveness of the work with respect to the programming languages is a desire to success of reflection in producing the separate error handling from the programs required separation of concerns. normal operation [Burns and Wellings, 1996]. This is in line with the justification 1.1 Non-reflective Exception Models for the use of reflection in system design – in that its use aids in the separation of The exception model that we explore within concerns. this paper is derived from the common non- reflective one of exceptions being raised Despite this desire for a separation, in many (thrown) and subsequently (possibly) caught approaches the handler code is still within a separate section of code (termed the intermingled with application code, albeit exception handler) usually at the end of an moved to the end of a program block. In this exception block. Exceptions that are not paper we explore the use of reflective caught by any exception handler currently principles to complete the separation of within scope are propagated back up to the concerns by attempting to operate on previous level – the caller – and the search exceptions at the metalevel. for a handler repeated. This model follows The remainder of this introduction describes that used in many current object-oriented the exception model that we have used as and procedural languages such as Ada95 the basis for our work and explores the [Intermetrics, 1995] and C++ [Stroustrup, motivation for producing a reflective 1997]. Both Ada95 and C++ use the treatment of exceptions. The second section termination model of exception handling – describes two variations of the model, the once an exception has been handled the first in Section 2.1 considers a model where exception block is terminated and control the raising of the exception is reified returns to the containing block or caller as whereas Section 2.2 considers a scenario appropriate. The alternative method of where the exception itself is the reified processing is the resumption model where entity. Next Section 3 explores further issues control is returned to the containing block after the exception has been handled. This is language model [Watanabe and Yonezawa, not as common as the termination model and 1988; Maes, 1987] inorder to develop the is not implemented in any ‘mainstream’ most general result. Within this general language. Furthermore, the resumption reflective architecture, the structure and model can be implemented in a number of behaviour of an object is controlled by its flavours – re-execute from the start of the metaobject, which itself is controlled by a exception block, re-execute the instruction meta-metaobject. Unlike many reflective which caused the exception or resume object-oriented languages, we allow a base- execution at the instruction following the level object to have multiple metaobjects “faulty” instruction. each responsible for some aspect of structure and/or behaviour of the base-level object. Within a program it is possible, and important, to distinguish between two 1.3 Motivation different types of exception depending on their source: Exception handling can be viewed as providing error containment for an object • Environmental – The exception is raised and helps to prevent errors propagation by an entity (e.g. the run-time system) within the system. The issues related to outside the current program due to an exception handling within an object-oriented event occurring in the environment context have been considered by a number within which the program is running, for of authors, notably [Miller and Tripathi, example, a floating point error raising the 1997]. However, we are not aware of any CONSTRAINT_ERROR exception in an work that addresses issues related to Ada95 program. reflection and exceptions. In a reflective • Application – The exception was defined system, the metalevel reifies (makes within the program code and is raised as a concrete in terms of actually implementing) result of a program action (or inaction). the abstractions used by the base-level. We For example, an exception raised as the thus view exceptions as implementing the result of a failed application assertion. abstraction of fault-free objects/modules within a system and that using a more In addition, either type of exception can be explicit reflective model would enable us to synchronous or asynchronous. A exploit the further advantages offered by synchronous exception is raised as a direct reflection. These are: result of current program activity, e.g. resource locked, whereas an asynchronous • A strong, disciplined separation of exception is not related to the current concerns – Our initial motivation for program activity though the exception may this work stemmed from a belief that the have been raised as a result of past activity separation of concerns offered by a or current in-activity. Note that for reflective treatment of exceptions could application exceptions the asynchrony can provide a useful extension of their use to be viewed as the insertion of an arbitrary divide functional and error-handling delay between the exception being raised code. In addition, we want to be able to and the subsequently being handled support a wider range of features (e.g. different exception models) than can be 1.2 Reflective Programming Model accommodated in a non-reflective Within this paper we aim to produce a language. A reflective system permits an reflective treatment of exceptions and thus effective discipline to be imposed on the follow the usual reflective object-oriented separation since the metalevels can impose the required restraints on change 2.1 Reifying the raising of an within the system. exception • Transparency and self-containment – The first reflective model of exception These refer to the principles that the handling we shall consider uses a base-level is not reliant on the metalevel computational model with two distinct for correct functional behaviour and that entities; objects and exception handlers. An the facilities implemented by the object throws an exception which is metalevel are transparent to the base- subsequently processed by an exceptions level. Viewed from the perspective of an handler. Reflection is used to reify the act of application, facilities reified by the raising/throwing the exception; thus when an metalevel are seen as not relevant to the exception is raised, a jump to the metaobject provision of correct functional operation. occurs that then handles exception through Note that system requirements, e.g. fault the exception handler along with any other tolerance or security, may well be processing undertaken by the metalevel. implemented at the metalevel. However, This procedure is analogous to the if they are not available the application reification of a method call that causes an will still operate except that it would interception of the call to the base-level execute without the safety net of the object with subsequent processing controlled fault-tolerance or security layers by the metaobject. insulating the application from an unreliable insecure execution environment. • Recursive – The metalevel reifies abstractions used at the base level and L E the recursive nature of the reflective V E Metaobject Metaobject L A model means that the meta-metalevel T E reifies abstractions used at the metalevel. M ê L E This principle means that we seek V E L E consistency of programming language S å A entities at each meta-level. B Exception Baselevel Baselevel handler object B object A 2 Exceptions and Reflection This section describes the development of Figure 1: Exception our first model of reflective exceptions. The handling with reified basic principle of operation is that the act of exception raise. raising of an exception becomes a reified Figure 1 illustrates how an exception is operation. After briefly presenting the model raised and handled within this system. The we will discuss why such an approach is not flow of control proceeds as follows: adequate and show how the basic model can 1. Base-level object “A” invokes a method be changed to enhance the separation in “B”. The invocation is trapped by the between functional and exceptional code. metalevel. 2. The metaobject invokes an appropriate method in the base class in response to the invocation request from “A”. 3. At some point an exception is raised 2.1.1 Exception Propagation which, since this is a reified operation, causes a jump to metaobject If the exception cannot be processed (e.g. computation. there is no handler present) then the metaobject must propagate the exception to 4. The metaobject invokes the selected the invoker’s meta-object with possible handler which may access/modify the subsequent termination of the method state of “B” to resolve the exception. invocation that raised the exception. The call The handler returns information to the to the base-level object which actually raised metaobject indicating the success or the exception should be terminated otherwise of the exception handling. irrespective of the exception termination 5. The metaobject decides on the fate of the model currently in use – after propagation, method invocation request from “A”. In even for the resumption case, the invoker this example it terminates the original object is the one to be resumed.