Concurrency and failures are fundamental problems in distributed computing. One likes to think that the mechanisms needed to address these problems can be separated from the rest of the distributed application: in modern words, these mechanisms could be aspectized. Does this however make sense? This paper relates an experience that conveys our initial and indeed biased intuition that the answer is in general no. Except for simple academic examples, it is hard and even potentially dangerous to separate concurrency control and failure management from the actual application.

New software architectures based on multi-agents or software components allow the integration of separately developed software pieces that interact through various communication schemes. In such a context, reliability raises new important issues. This paper aims at increasing reliability in multi-agent systems (MASs) and, therefore, focuses on the study of an appropriate exception handling system (EHS). The issues specific to exception handling in MASs -- preservation of the agent paradigm and support of cooperative concurrency -- are presented and discussed. This paper analyses existing EHSs according to these issues and describes our proposition, the Sage system, which integrates various solutions from existing EHSs and adapts them to the agent paradigm. Sage is an exception handling system dedicated to MASs that addresses the stressed issues by providing means to coordinate the collective activities of agents, to embbed contextualized handlers in agents and to concert exceptions. It has been implemented and integrated in the MadKit MAS. It has been experimented with a classical travel agency case study.

Abstract Asynchronous Active Objects (AAOs), primarily exempli ed by actors [1], nowadays exist in many forms (various kinds of actors, agents and components) and are more and more used because they t well the dynamic and asynchronous nature of interactions in many distributed systems. They raise various new issues regarding exception handling for which few operational solutions exist. More precisely, a need exists for a generic, simple and expressive, programmer level, exception handling system that appropriately handles the following main exception handling issues or requirements in the context of AAOs: encapsulation, object autonomy, coordination of concurrent collaborative entities [2], caller contextualization [3], asynchronous signaling and handler execution, resolution of concurrent exceptions [4,5], exception criticality [6] and object reactivity. This paper presents the speci cation of an evolution of the Sage exception handling system [7], which provides solutions to those issues in the context of systems developed with active objects using one way asynchronous communications and interacting via the request / response protocol. Such a context, in which synchronizations constraints are, when needed, handled at the application level, allows for a very generic view of what could be done regarding exception handling in all systems that use active objects. The Sage solution is original and provides a good compromise between expressive-power and simplicity.

Exception handling in Ada has a number of well-known problems. It allows for the propagation of unhandled and anonymous exceptions, it is error-prone and it is inappropriate for some language features including tasking and tagged types. Ada programs with exceptions are difficult to understand, develop, modify or analyse, and the exception handling features can be misused in a number of ways. In this paper we introduce the requirements for good exception handling features. We classify the problems with Ada exception handling into two subsets: serious conceptual problems that require an improvement of the language features, and problems attributable to the misuse of the existing features. Problems in the second category can be solved by improving programmers ' understanding of the features and ways of using them. 1. Good Exception Handling Exception handling was introduced as a disciplined and structured way of handling abnormal system events without complicating the normal code and without resorting to the use of "goto". (It could be argued, however, that the exception handling features rely on a structured and restricted form of "goto".) Many researchers regard exception

Abstract: Exception handling is a very popular technique for incorporating fault tolerance into software systems. However, its use for structuring concurrent, distributed systems is hindered by the fact that the exception handling models of many mainstream object-oriented programming languages are sequential. In this paper we present an aspect-based framework for incorporating concurrent exception handling in Java programs. The framework has been implemented in AspectJ, a general purpose aspect-oriented extension to Java. Our main contribution is to show that AspectJ is useful for implementing the concerns related to concurrent exception handling and to provide a useful tool to developers of distributed, concurrent fault-tolerant applications.

Designers of component-based software face two problems related to dealing with abnormal events: developing exception handling at the level of the integrated system and accommodating (and adjusting, if necessary) exceptions and exception handling provided by individual components. Our intention is to develop an exception handling framework suitable for component-based system development by applying general exception handling mechanisms which have been proposed and successfully used in concurrent/distributed systems and in programming languages. The framework is applied in three steps. Firstly, individual components are wrapped in such a way that the wrappers perform activity related to local error detection and exception handling, and signal, if necessary, external exceptions outside the component. At the second step the execution of the overall system is structured as a set of dynamic actions in which components take parts. Such actions have important properties which facilitate exception handling: they are atomic, contain erroneous information and serve as recovery regions. The last step is designing exception handling at the action level: each action (i.e. all components participating in it) handles exceptions signalled by individual wrapped components.