Aspects of Exceptions at the Meta-Level (Position Paper) Ian S. Welch 1 , Robert J. Stroud, and Alexander Romanovsky Department of Computing, University of Newcastle upon Tyne, United Kingdom NE1 7RU {i.s.welch, r.j.stroud, alexander.romanovsky}@ncl.ac.uk http://www.cs.ncl.ac.uk/research/dependability/reflection/ 1 Introduction This paper describes the design and usage of a metaobject protocol that explic- itly includes support for handling exceptions. We do not propose implementing exception mechanisms anew [3, 5] or proposing a unified meta-level software ar- chitecture for exception handling [4]. To make our discussion concrete we de- scribe an extension of the Kava [9] metaobject protocol that includes exceptions as first class values, provide examples of Kava’s use, and compare Kava with related Java extensions. We believe that insufficient attention has been paid to exceptions by de- signers of metaobject protocols for object-oriented languages. Most metaobject protocols provide a way of intercepting method execution but these protocols are usually discussed solely in terms of arguments and results. Signalled exceptions are rarely discussed. However, in order to successfully implement non-functional requirements using metaobject protocols it is important that exceptions are ex- plicitly considered. For example, consider using a metaobject protocol approach to implement distributed objects. It is not sufficient just to convert method calls into remote method calls, exceptions must be converted into remote exceptions as well. Therefore, a metaobject protocol should be designed to treat method arguments, method return values and exceptions equally. This means that if the behaviour of method execution is reflected upon, then any signalled excep- tion should be reified and be manipulable at the meta-level. Note that such a “exception-aware” metaobject protocol should not lead to base-level program- mer’s expectations being confounded, as doing so would make both programming and verification very difficult. For example, the exception model should not be able to be changed dynamically, say from a termination model to a resumption model (as opposed to [2]). 2 Meta-Level Requirements What facilities should a “exception-aware” metaobject protocol have? We pro- pose that such a metaobject protocol needs two facilities: meta-level interception