Exception handling in multi-agent oriented programming

Abstract

Exception handling has been successfully proposed in the past years as a simple yet powerful software engineering tool to promote modularity and decoupling, while also preserving robustness. Multi-agent systems (MAS) and organizations (MAOs), in turn, offer powerful abstractions to build distributed systems; current models and methodologies, however, fall short in addressing exception handling in a systematic way, not considering exceptions as part of their design. Thus, the problem is usually approached by ad hoc solutions that hamper code modularization and decoupling. In this work, we outline a vision of how exception handling in MAS can be granted by design. We present an extension of the organizational model and infrastructure adopted in JaCaMo, that explicitly encompasses the notion of exception as a first-class element in the design of an organization. Relying on such a model, we propose an exception handling mechanism that is seamlessly integrated with organizational concepts, such as responsibilities, goals, and norms. In an organization, besides responsibilities for organizational goals, we propose to specify also responsibilities for managing exceptions, that is, for providing feedback about the context in which exceptions occur, and for handling it.

1. Introduction

A software program can encounter, during its executions, conditions that were not foreseen, sometimes by mistake, during the implementation. Think, for instance, to the common experience of a badly controlled for-loop that should initialize an array of values but exceeds its boundary. More interesting, however, is the case when the unforeseen situation is not due to a programming mistake, but rather to the weird behavior of a user (who, for instance, digits the string ‘fiftyone’ instead of the expected number 51), or to unforeseen environmental conditions, like a black-out. When this happens, the program becomes unreliable if unable to properly tackle the case.

Many programming languages allow programmers to tackle such cases by providing exception handling mechanisms, which can be used to enrich the code for specifying exceptions, that will be raised when, along the execution, certain conditions are met. An exception is often intended as an ‘event that causes suspension of normal program execution’ (ISO/IEC/IEEE, 2010). When an exception is raised suitable handlers are activated to manage the situation and allow the program to maintain a reliable behavior. Proposals like (Goodenough, 1975a,b,c) see exceptions as a means for extending the domain (i.e., the set of inputs for which effects are defined—as in the ‘fifty-one’ case), or the range (i.e., the effects obtained when certain inputs are processed—as in the array initialization case) of a piece of code, in a way that allows the invoker to tailor the management to the specific context of use—for instance, by writing a feedback to the user asking to insert digits instead of letters.

In general, the full significance of an exception is known only outside the detecting code, which cannot determine unilaterally what is to be done after an exception is raised. Indeed, in many programming languages it is up to the ‘invoker’ to control the response to the exceptions that are raised by the ‘invoked’ method or function. For this reason, exceptions, besides notifying the occurrence of some unexpected event, are generally implemented as typed data structures, that allow passing to the handler all the relevant contextual information about the occurrence at issue (Hagen & Alonso, 2000).

Scaling from monolithic to distributed systems, the picture becomes more complex. Here, many threads/processes are executed in parallel. Exceptions might be raised in a thread/process that should be handled by another, but there is not a notion of ‘invocation’ to be leveraged upon. Some proposals concerning Akka and workflow management, for instance (Hewitt et al., 1973; Hagen & Alonso, 2000; Gupta, 2012; Goodwin, 2015), organize the execution of threads by way of parent–child relationships: when a child process raises an exception, its parent handles it. When we come to multi-agent systems (MAS) (Wooldridge, 2009), however, no structural relationships, like the mentioned invoker-callee and parent–child, exist. Thus, although it may happen that an agent failure has an impact on the activities carried out by other agents, even identifying which agents should be capable of raising which exceptions, and which other agents should be capable of handling them, is challenging. The reasons are that agents are peers which interact by message exchange, and each agent is autonomous in its deliberative process—even when it cooperates and coordinates with others in order to accomplish its goals. For instance, consider a doctor and one of his or her patients. The patient emails some symptoms to the doctor without receiving any answer (because the message was lost). In this case, only the patient agent can realize that something went wrong and hence can raise an exception about the lack of feedback, which can then be handled by the doctor. Instead, in case the doctor cannot prescribe what requested, it is the doctor agent that can raise the exception, and the patient is the one who should handle it.

In this paper, we outline a vision of how exception handling can be seamlessly integrated in MAS design and development. To face the inherent need of coordination among autonomous agents, the organization metaphor has been used for a long time in MAS. Since the initial proposals, like (Corkill & Lesser, 1983; Dignum, 2009), agent organizations encompass an explicit structure of roles and relations; responsibilities of tasks are distributed among the participating agents by role adoption. Thanks to norms (Esteva et al., 2001), the structures of distributed responsibilities among agents have been enriched with structures of social expectations, making roles the anchoring point of social expectations on the behavior of the agents who will play them in the organization. In particular, normative multi-agent organizations (MAO) (Dardenne et al., 1993; Bauer et al., 2001; Bresciani et al., 2004; Hübner et al., 2007; Boella et al., 2008; Boissier et al., 2013; Boissier et al., 2020) provide mechanisms to publish, enact, adapt, monitor and enforce normative behaviors. Thus, once decided to adopt a role, with the accompanying norms, in order to participate to the organization, agents assume the responsibility of the targeted tasks and are expected to accomplish their duties.

Under this perspective, we claim that the raising and handling of exceptions are tasks that should be encompassed in the MAS as part of the specification of its organization, consequently falling under the responsibility of specific agents. More specifically, the contribution of this paper is twofold. First, the paper introduces a model that defines exceptions at both the organizational and the agent level, explaining the key concepts. Second, building on the conceptual meta-model presented in Baldoni et al. (2022), we explain how the JaCaMo platform was modified in order to support the implementation of MAOs with exceptions, providing insights not only into the technical changes but also into the rationale behind them. Note that, although we focus on explaining how we grafted exception handling on JaCaMo’s architecture, the approach is general and could be adopted beyond the community strictly working with JaCaMo. We help the explanation by illustrating the realization of complex examples taken from the literature, and in particular inspired by Christie et al. (2021), that show how exceptions can be of use in practical, real-world scenarios.

The paper is structured as follows. Section 2 recalls the main concepts about JaCaMo and introduces the extension of JaCaMo’s meta-model with exception handling. Section 3 presents in detail how we integrated the proposed exception handling mechanism into JaCaMo’s organizational infrastructure. Section 4 discusses the most relevant related works concerning exception handling in MAS. Discussion and conclusions end the paper.

2. Exception handling in JaCaMo

JaCaMo (Boissier et al., 2020) is one of the best-known platforms for programming MAO and integrates three different dimensions: agents, environments, and organizations. JaCaMo agents are programmed in Jason (Bordini et al., 2007). An agent is an entity composed of a set of beliefs, representing the agent current state and knowledge about the environment, a set of goals, which correspond to tasks the agent has to perform, and a set of plans which are courses of actions, either internal or external, triggered by events, that can be taken by the agent in given circumstances. The agent environment consists of a dynamic and distributed set of shared artifacts that are programmed in CArtAgO (Ricci et al., 2009). Each artifact provides to the agents the interface (set of operations), through which it can be used. Thus, agents can both perceive the artifact observable state, reacting to events, and act upon an artifact by performing the artifact-provided operations.

2.1 Specification of a basic organization

JaCaMo organizations are programmed in Moise (Hübner et al., 2007). The organizational model structures the specification of an agent organization along three dimensions (Hübner et al., 2010). The structural dimension specifies roles, groups, and links between roles in the organization. The functional dimension encompasses one or more schemes that elicit how the global organizational goals are decomposed into subgoals and how these subgoals are grouped in coherent sets, called missions, to be distributed to the agents. The normative dimension binds the previous two by specifying the role permissions and obligations for missions. Agents, in fact, are held to explicitly commit to the missions defined in the scheme, thereby taking responsibility for mission goals. Organizational goals are mapped into individual agent goals. Obligations to achieve organizational goals are issued according to the normative specification of the organization and the current state of the system. An obligation is fulfilled when the corresponding goal is achieved by the recipient agent before a given deadline. During the execution of a scheme, the involved goals can be in the state waiting (the goal cannot be pursued yet because it depends on the satisfaction of other goals), enabled (the goal can be pursued; its preconditions have been satisfied), or achieved (the agents were able to achieve the goal). The organizational infrastructure is designed as a part of the environment in which agents are situated by means of some dedicated organizational artifacts, upon which agents can perform operations.

At runtime, the organizational specification is translated into a normative program, written in a specific language, called NOPL (Hübner et al., 2009, 2010, 2011). The interpretation of such a program is performed by a dedicated interpreter, included in each organizational artifact, and regulates the functioning of the organization. A normative program in NOPL is composed of: (i) a set of normative facts, either translated from the specification or added dynamically during the execution, (ii) a set of inference rules, and (iii) a set of norms. The specification of normative facts and inference rules follows a syntax that is similar to the ones used in Jason and Prolog. In case of prohibition, norm activation results in the failure of the action which triggered the norm. Otherwise, the result is the emission of an obligation directed toward some agent and concerning a state of the world that the agent ought to bring about.

Let us, now, introduce the running example that we will use along the paper. It is inspired by Christie et al. (2021), an article concerning fault tolerance in MAS. With reference to Figure 1:

Figure 1. The Therapy scenario

Example 1 (Therapy) The scenario involves a patient, a doctor, and a pharmacist:

• • The patient consults the doctor explaining some symptoms and then waits for the medicines in order to follow the therapy.

• • The doctor prescribes the medicines and communicates the prescription to the pharmacist.

• • The pharmacist fills the prescription and has the prescribed drugs delivered to the patient.

An additional constraint is that medicines must be taken within five days.

In order to implement the example in JaCaMo, it is necessary to realize an organization that involves agents playing the roles patient, doctor, and pharmacist. Such roles are part of the structural specification of the organization (Lines 3–7 in Listing 1). The functional specification of the organization (Lines 16–39) tells how the organizational goal ( $\mathsf{therapy}$ ) is structured into subgoals that are grouped into missions and assigned to roles by way of the normative specification (Lines 40–44). In our case, the subgoals are $\mathsf{consult}$ and $\mathsf{follow\_therapy}$ (assigned to patient), $\mathsf{prescribe}$ (assigned to doctor), and $\mathsf{fill\_prescription}$ (assigned to the pharmacist). In this context, explain(symptoms), send(prescription), and deliver(drugs) are actions executed while pursuing the goals associated with the roles (see Listings 3, 4 and 5). The agents playing the various roles will have plans that allow them to achieve their goals. In our example, in the plan for achieving the subgoal $\mathsf{consult}$ , the patient will explain the suffered symptoms to the doctor, while in the plan for achieving goal $\mathsf{prescribe}$ , the doctor will send the prescription to the pharmacist. Last but not least, for achieving goal $\mathsf{fill\_prescription}$ , the pharmacist will deliver the drugs to the patient. Besides this, we require that $\mathsf{follow\_therapy}$ be achieved within five days after the consult.

Listing 1. Organization structural, functional, and normative specifications.

As usual in JaCaMo, the execution of such plans is coordinated, within the organization, by the emission of obligations, whose activation depends on what occurred that far. By means of a built-in library (see Listing 2), obligations are mapped into agents internal goals that can, then, be practically pursued by the agent, for example, by executing some operations over the environment. In case of success, the corresponding organizational goals are set as achieved by means of the $\mathsf{goalAchieved(...)}$ primitive that is made available by the organizational infrastructure.

Listing 2. JaCaMo library that maps organizational obligations onto agents’ internal goals.

Below, we report a skeleton implementation of a patient agent. The agent can handle two goals, $\mathsf{consult}$ (the doctor) and $\mathsf{follow\_therapy}$ . The former is achieved by executing a plan that simply sends a message to the doctor, which explains the suffered symptoms. The latter involves waiting for medicine delivery, and then taking the prescribed drugs.

Listing 3. Excerpt of the patient agent’s code.

Figure 2. JaCaMo’s conceptual meta-model extended for exception handling. The newly added concepts are highlighted in orange. Orange lines also highlight the mapping among concepts belonging to different dimensions

Similarly, the doctor and the pharmacist pursue their assigned goals as sketched hereafter.

Listing 4. Excerpt of the doctor agent’s code.

Listing 5. Excerpt of the pharmacist agent’s code.

2.2 Adding exceptions

Let us, now, see how exception specification and exception handling are introduced in the picture. Figure 2 reports the meta-model of our proposal. It enriches a previous meta-model, described in Baldoni et al. (2022), with elements that were disregarded in that proposal, like the environment dimension and the mapping between concepts belonging to different dimensions, thus providing a complete picture. Such a mapping is central in the implementation of the infrastructure (for details, please, check Section 3).

In Baldoni et al. (2022), an exception is a piece of information that concerns the result of an operation, which is needed to interpret such a result and to identify the right prosecution. The functional specification of the organization includes, in the scheme, a set of notification policies, whose general template is reported in Listing 6. A notification policy concerns an organizational goal (target) and specifies an activation condition (condition): a logical formula that encodes the state of the organization, and the target goal in particular, in which the policy must be applied. Such conditions can amount to the failure, the delay, the achievement of a goal or some combination. Table 1 contains some relevant types of condition together with their corresponding NOPL formulas: clause $\mathsf{scheme\_id(S)}$ identifies the functional decomposition scheme instance to which the condition refers. Placeholders starting with $ represent goal identifiers. Other conditions can be expressed as well, by directly specifying the corresponding NOPL formula as attribute. Note that it is possible to define many notification policies having the same goal as target, each having a different activation condition. In addition, a notification policy includes the definition of one or more exceptions that can possibly be raised, by means of the dedicated tag $\mathsf{report}$ . Each report specifies the structure of the information that will be exchanged, together with some raising and handling goals. Raising and handling goals are subject to further conditions that control their use.

Table 1. Condition types for notification policies. When the organization is made of a single functional decomposition scheme instance $\mathsf{scheme\_id(S)}$ can be omitted

Listing 6. XML template for notification policies. $+$ indicates one or more occurrences of the element between square brackets, $*$ indicates zero or more occurrences, and $?$ indicates optional elements.

Let us now explain each field of a notification policy.

Reports capture the shape of the information that the agents responsible for raising the exception have to provide to those in charge for handling it (i.e., the feedback Hagen & Alonso, 2000; Alderson & Doyle, 2010). More in detail, reports include a set of arguments—predicates (with their arity) that must be instantiated and made available by the raising agents. Intuitively, a report is a form to be filled in by the agents in charge of raising the exception. The filled form amounts to the actual exception that is raised and made available to the handling agents. If a report includes multiple arguments, we assume that all of them will be instantiated. Each report also includes at least one raising goal and at least one handling goal. These are the organizational goals through which the exception is managed. Note that a single notification policy may include many reports. This feature is, for instance, handy when the system designer deals with events showing many facets, with possibly many consequences on the system. It will require several (generally uncoordinated) actions, by different agents, to properly tackle all of them at system level.

Raising goals and handling goals, denoted by tags $\mathsf{raise-goal}$ and $\mathsf{handle-goal}$ , are the organizational goals that allow managing exceptions. As standard goals in JaCaMo, raising and handling goals are included in missions, to which the agents, that play organizational roles, commit. Each report contains at least one raising goal and one handling goal, but it may encompass many of both types. So, the same exception could be raised (and handled) in different ways in different circumstances, which are captured by the optional when clause, whose value corresponds to a state of the organization in which it makes sense to pursue that goal. Such a state amounts to a logical formula in NOPL, just like policy conditions (see Table 1).

Note that the act of raising an exception may require the joint efforts of many agents, as well as many agents may be involved in handling a raised exception. The involved agents may each be requested to carry out the same action, or they may be distributed different tasks which altogether produce the desired outcome. Thus, for each raising and handling goals, there may be many committed agents (exploiting JaCaMo’s mission cardinality). Finally, raising and handling goals (like all goals in JaCaMo) might be structured, that is, they might be composed of many sub-goals, requiring the collaboration of many agents to collect and make the relevant information available.

The management of exception raising and handling through obligations and through the normative system of the MAO clearly identifies agents’ responsibilities. In general, the agent that detects the conditions that will lead to raising an exception might not be equipped with the means to properly address the situation. It might not be able to determine the impact of the situation on the overall system. The exception handling mechanism we have introduced allows conveying relevant contextual information to those agents that are actually equipped with the means to promptly tackle them. This might be a complex process, involving many agents engaged in complex workflows. This is achieved by exploiting JaCaMo’s standard notions of goal cardinality and decomposition.

Let us, now, illustrate the specification of notification policies with reference to the Therapy scenario and to Figure 3.

Figure 3. The Therapy scenario extended with exception handling

Example 2 (Exception Handling in Therapy) Five days have passed and the patient has not received the needed medicines yet.

The failure of the patient’s goal $\mathsf{follow\_therapy}$ may be due to different circumstances:

1. 1. The doctor did not receive the symptoms sent by the patient;

2. 2. The doctor received the symptoms, but did not produce the prescription;

3. 3. The pharmacist filled the prescription, but the medicine did not arrive to the patient;

4. 4. The pharmacist delayed the preparation of the medicine;

5. 5. The pharmacist did not receive the prescription produced by the doctor.

These situations cause the failure of one or more organizational goals. We use these failures to discriminate between alternative exceptions and how to handle them. At the level of the organizational specification, we specified a notification policy (Listing 7) and added it to the scheme in Listing 1, with target $\mathsf{follow\_therapy}$ and with activation condition unfulfilled(obligation(_, _, done(_, follow_therapy, _), _)). In our scenario the deadline was missed, and indeed this condition corresponds to the condition type ‘goal delay’ in Table 1 (the scheme reference is omitted for brevity).

Cases (1) and (2) are detected by goal $\mathsf{prescribe}$ not being satisfied. In these cases, the patient is the one who must raise the exception, informing the doctor that the symptoms went lost: the patient will supply the date of the sending so that the doctor will sort out what happened (the doctor handles the exception). In Figure 3, this part is represented by the dotted red arrows. In the notification policy, the exception is specified with the name $\mathsf{exception\_lost\_symptoms}$ (see Lines 3–8 in Listing 7). The report includes two arguments, the date and the list of symptoms, the raising goal $\mathsf{raise\_exception\_lost\_symptoms}$ that can be raised when condition not satisfied(_, prescribe) holds, and the handling goal $\mathsf{handle\_exception\_lost\_symptoms}$ . The raising and handling goals are part of missions, see Lines 27–38 in Listing 7. Missions are associated with roles through the normative specification at Lines 40–44 in Listing 1.

Cases (3) and (4) become of interest when $\mathsf{prescribe}$ is satisfied, but the patient has not received the medicines. The patient should, in this cases, raise an exception toward the pharmacist (who will have the role of exception handler). This is possible because in JaCaMo a goal state is a public observable property of the organizational artifacts, so a patient can know whether a prescription was done by looking at the state of the organizational goal $\mathsf{prescribe}$ . The patient will supply the date of the consult and the doctor’s name, so that the pharmacist can sort out what happened.

The pharmacis has two handling goals because it may either be the case that the prescription was filled (and the delivery failed), or the prescription for some reason has not been filled yet. The latter case may be due to the pharmacist, who is late and will then solve the problem. However, it may also be due to some error in the communication of the prescription from the doctor, which amounts to case (5). In this case, the pharmacist will, in turn, raise an additional exception toward the doctor, containing the patient’s and doctor’s names and the date of the consultation at issue, to solve the problem. This can be done by declaring the failure of the pharmacist’s goal $\mathsf{fill\_prescription}$ . In Figure 3, dotted blue arrows capture cases (3) and (4), while dotted green arrows capture case (5). In the notification policy, $\mathsf{exception\_no\_delivery}$ includes the date and the name of the doctor, as arguments. It includes the raising goal $\mathsf{raise\_exception\_no\_delivery}$ that can be raised when the condition satisfied(_, prescribe) holds. Such a condition corresponds to the type ‘goal achievement’ in Table 1. The exception specification also includes two handling goals. The first, $\mathsf{handle\_exception\_no\_delivery}$ , is used when the pharmacist has filled the prescription. The second, $\mathsf{handle\_exception\_no\_delivery\_no\_fill}$ , is used when the pharmacist has not satisfied the goal $\mathsf{fill\_prescription}$ , and will have to understand whether it is its fault or a lack of communication from the doctor. This last case calls for the specification of a further report, called $\mathsf{exception\_missing\_prescription}$ , which has two arguments: the patient’s name, and the date of the consultation. It includes the raising goal $\mathsf{raise\_exception\_missing\_prescription}$ that can be pursued when satisfied(_, prescribe) and failed(_, fill_prescription). The handling goal, $\mathsf{handle\_exception\_missing\_prescription}$ , is up to the doctor.

Listing 7. Notification policy for the Therapy scenario.

2.3 Agent programming with exceptions

Now coming to agent programming, Listing 8 shows the extended implementation of the patient agent, where the first two exceptions are raised.

Listing 8. Excerpt of the patient agent’s code extended with exception handling.

The first three plans allow the agent to pursue its assigned goals from the functional decomposition, while the last two are related to exception handling. More in detail, as soon as the scheme execution starts the agent receives two obligations: to pursue goals $\mathsf{consult}$ and $\mathsf{follow\_therapy}$ . The obligations are automatically mapped onto the agent internal goals and the corresponding plans are activated. It is worth noting that the agent is able to successfully complete the plan at Line 7 only if the drugs are received from the pharmacist (see the plan context). Should this not happen before five days, the obligation to achieve goal $\mathsf{follow\_therapy}$ would become unfulfilled. Consequently, the notification policy in Listing 7 would be triggered (see line 1). This causes the emission of new obligations concerning the raising/handling of exceptions.

In our case, the patient is able to raise two exceptions ( $\mathsf{exception\_lost\_symptoms}$ and $\mathsf{exception\_no\_delivery}$ ), but it will actually raise only one of the two, depending on the context. The last two plans in the agent code serve this purpose: the agent raises the appropriate exception by means the primitive $\mathsf{raiseException(...)}$ (Lines 12 and 16), which takes in input a list of arguments that complies with the expected report specification. Such arguments are made available to the handler agents as observable properties of the organizational artifacts.

When raising $\mathsf{exception\_lost\_symptoms}$ , the agent will have to provide the consultation date and the symptoms, while when raising $\mathsf{exception\_no\_delivery}$ , the agent will have to provide the date and the doctor’s name. The reason is that the first exception is to be handled by the doctor, while the second by the pharmacist. Since the pharmacist may receive prescriptions from multiple doctors, the information is needed to identify the right one. This example shows that report arguments encode relevant contextual information that must be provided from the raiser to the handler in order to allow the latter to cope with the exception at hand.

The achievement of a raising goal implies the emission of an obligation toward the agents that should achieve the associated handling goals. In our example, the raising of $\mathsf{exception\_lost\_symptoms}$ enables the handling goal $\mathsf{handle\_exception\_lost\_symptoms}$ , which is in charge to the doctor. The exception $\mathsf{exception\_no\_delivery}$ , in turn, encompasses two different handling goals (in charge to the pharmacist). As explained the two goals are enabled in different circumstances, that are specified by the $\mathsf{when}$ condition.

Listing 9 below reports the code of the pharmacist agent, extended for handling the $\mathsf{exception\_no\_delivery}$ , raised by the patient.

Listing 9. Excerpt of the pharmacist agent’s code extended with exception handling.

The plans at Lines 5, 9, and 14 target the handling goals. The first one is triggered when the agent, which has filled the prescription, receives the exception that was raised by the patient. This means that the drugs went lost before reaching the patient. The exception is handled by organizing another delivery of the prescribed drugs.

The remaining two plans capture cases (4) and (5) in Example 2. Here the pharmacist did not fill the prescription. This could be due to many reasons, we consider two alternatives: (1) the preparation for some reason was delayed and (2) the pharmacist did not receive the prescription from the doctor. The two plans in Listing 9 tackle the two cases. While in the first case the exception is handled totally and directly by the pharmacist that will simply fill the delayed prescription, the second case is more complex. The agent cannot activate the plan to achieve the goal $\mathsf{fill\_prescription}$ because the context at Line 1 does not hold. The agent, thus, marks the organizational goal as failed by means of the $\mathsf{goalFailed(...)}$ operation, at Line 15. This operation is provided by our the extended infrastructure and allows agents to proactively signal the failure of their organizational goals. The failure triggers the raising of a further exception (the last one specified in the notification policy). According to the policy, $\mathsf{exception\_missing\_prescription}$ must be raised by the pharmacist and handled by the doctor. The plan at Line 17 allows the agent to raise the exception. It is worth noting that the pharmacist may leverage the arguments provided beforehand by the patient while raising the previous exception (see the plan context). In this case, the date of the prescription and the patient’s and doctor’s names are forwarded to the doctor.

Finally, Listing 10 shows the doctor’s code, extended with exception handling. The agent includes two plans that allow it to handle both the exceptions raised by the patient and by the pharmacist. To do so, the agent must achieve the corresponding handling goals. Here, we see again that the agent can leverage the information provided by the exception (i.e., the list of lost symptoms) to determine what has to be done.

Listing 10. Excerpt of the doctor agent’s code extended with exception handling.

3. Exceptions as part of the organization infrastructure

To include exception handling as a primitive mechanism in JaCaMo ¹ , and so allow the specification and the execution of MAOs with exceptions, we had to work at three different levels:

1. 1. Specification level: we had to provide the means to enrich the specification of an organization with a set of notification policies;

2. 2. Normative level: we had to enable the enforcement of the normative behavior, yielded by notification policies, by issuing obligations to achieve raising and handling goals;

3. 3. Infrastructural level: we had to enrich the organizational infrastructure with the functionalities needed by agents to actually raise and handle exceptions.

Figure 4 illustrates the general picture of JaCaMo organizational component enriched with all the newly introduced elements (in orange the major changes). In particular, we extended three components: (i) the organizational specification, (ii) the normative program, and (iii) the organizational artifacts. In JaCaMo, organizational specifications are written in XML. At runtime, the XML specification is translated into a set of NOPL normative programs, which address groups and schemes. The organization management infrastructure is, then, realized through a set of artifacts, upon which the agents can operate. Such artifacts allow agents to interact with the organization, by perceiving its observable state and by executing operations (JaCaMo’s normative interpreter relies on these artifacts).

Figure 4. General architecture of JaCaMo’s organizational component. The parts affected by our extension are highlighted in orange

In order to capture exceptions and allow the interpretation of our extended normative program, we extended a specific class of artifacts for scheme management. Furthermore, we included a set of additional operations made available to the agents. The runtime functioning of our proposed extension is structured as follows.

3.1 Encoding notification policies in the normative program

Notification policies are specified in XML, but need to be translated into norms and rules to be interpreted by the normative system at runtime. To allow this to happen, we introduced some new organizational facts which allow capturing the notification policy structure. Table 2 lists them, together with an explanation of their meaning. So, for instance, $\mathsf{notificationPolicy(NP,Target,Condition)}$ is used to capture the fact that $\mathsf{NP}$ is a notification policy that concerns the goal $\mathsf{Target}$ and is activated when the specified condition holds (for instance, when the target goal fails). These facts, however, are not sufficient because we also need to capture dynamic facts that occur at runtime. These dynamic facts are produced as a consequence of specific operations performed by agents on some artifacts and regard the raising and handling goals.

Table 2. Normative facts capturing notification policies

For example, we just mentioned that a notification policy condition may amount to the failure of some goal, but standard JaCaMo only allows agents to mark goals as achieved, and hence we had to extend it to widen the set of goal states. In particular, we introduced the new artifact operation $\mathsf{goalFailed(G)}$ , by which an agent can signal the failure of goal $\mathsf{G}$ . As a consequence, the dynamic fact $\mathsf{failed(S,G)}$ is added in the normative state. Such a fact can appear in conditions triggering notification policies.

3.2 Enabling and accomplishing raising goals

At runtime, the normative systems checks, for each report in an active notification policy (i.e., with $\mathsf{Condition}$ satisfied), the presence of applicable (exception) raising goals. That is, raising goals whose $\mathsf{when}$ clause holds. This check is performed by means of the following rule.

A raising goal $\mathsf{RG}$ is enabled when the $\mathsf{Condition}$ defined for the policy it belongs to, as well as its local $\mathsf{When}$ condition, hold, provided that its dependencies (preconditions) are satisfied. The predicate $\mathsf{dep(...)}$ is built-in NOPL and encodes the dependencies of a given goal, that is, the other goals that must be achieved (or released) before the goal can be pursued. Dependencies are deduced automatically from the functional decomposition.

Once a raising goal is enabled, the normative system issues an obligation to the involved agent(s). Although this mechanism is common to all goals, raising goals are special because they produce a piece of knowledge—an exception—that is compliant with the report that is given in the notification policy, to which the raising goal at issue belongs. To perform this, we introduced a new artifact operation: $\mathsf{raiseException(E,Args)}$ allows an agent to raise an exception $\mathsf{E}$ with a list of arguments $\mathsf{Args}$ . Arguments are a set of ground predicates having the structures specified by facts $\mathsf{reportArgument(E, Functor,Arity)}$ for the report for exception $\mathsf{E}$ . The operation adds to the normative state the dynamic fact $\mathsf{raised(E,Ag,Args)}$ , where $\mathsf{Ag}$ is the name of the agent executing the operation and $\mathsf{Args}$ are the provided exception arguments. Note that the raised exception, together with its arguments is also made available to the other agents as an artifact observable property which has the shape $\mathsf{raised(E,Args)[raiser(Ag)]}$ .

3.3 Enabling and accomplishing handling goals

Raised exceptions must be handled, so, when an exception is raised, the normative system looks for handling goals that are enabled. This is done by means of the following rule.

Similarly to raising goals, a handling goal is enabled if its $\mathsf{When}$ condition holds, and if the precondition goals are satisfied. We additionally require that an exception has actually been raised, and that the corresponding raising goal has been satisfied. In this way, we ensure that the agent to which the handling goal is assigned, is able to take advantage of the information provided by way of the raising goal. It is possible that many handling goals are concurrently enabled for the same raised exception. Obligations are, then, issued for each enabled handling goal. The involved agents can leverage the information, encoded by the raised exception, to enact the most appropriate countermeasures and handle the exception.

In particular, the achievement of a handling goal could make no longer needed the goal whose failure triggered the exception. In such a case, the failed goal must be skipped. The new artifact operation $\mathsf{goalReleased(G)}$ allows agents to release an organizational goal $\mathsf{G}$ . It adds to the normative state the fact $\mathsf{released(S, G)}$ . Executing this operation allows the appointed agents to notify the organization that the exception was handled. The execution of the scheme $\mathsf{S}$ can proceed because $\mathsf{G}$ is not of interest anymore. This allows resuming the process, aimed at the achievement of the organizational goal, which would, otherwise, remain stuck.

It is worth noting that releasing a failed goal is just a possibility. For instance, as an alternative the handling agent could decide to retry its achievement by resetting it, after the restoration of a consistent context. Of course, the choice for the best way to handle an exception is up to the agent that should handle it.

3.4 Norms for dealing with exceptions

As a final step, we had to provide the normative program with the norms needed to issue obligations toward agents for raising and handling goals and to ensure a set of properties that guarantee the correct functioning of the exception handling mechanism. To illustrate, some of these norms ensure that only designated agents can raise or handle specific exceptions, or that an exception can be raised only if the condition of the enclosing notification policy actually holds. We recall that a norm is composed of a name, a set of facts that represent the activation condition of the norm, and a consequence condition. The consequence of a norm activation can be either the emission of an obligation or a failure. In the latter case, this results in the failure of the action that triggered the norm.

The first addition concerns the achievement of raising and handling goals, which is to be coordinated through obligations by the normative system—as for any other organizational goal. In order to allow a proper management, we had to modify the standard built-in norm for goal achievement, as reported in Listing 11: the norm does not issue anymore obligations concerning goals marked as failed or released (Lines 8–9).

Listing 11. NOPL norm issuing obligations to achieve goals.

Briefly, the norm says that if agent $\mathsf{A}$ is committed to mission $\mathsf{M}$ in scheme $\mathsf{S}$ and $\mathsf{G}$ is one of the mission goals (Line 3), such that $\mathsf{G}$ is either an achievement or a performance goal ² (Lines 4–5), the scheme is well-formed (Line 6), and $\mathsf{G}$ is ready to be achieved, then an obligation directed toward $\mathsf{A}$ to achieve $\mathsf{G}$ must be emitted (Line 11). Note that in JaCaMo a scheme is well-formed when all the mission minimum and maximum cardinalities are respected, that is, when all the needed role-player agents have committed to their missions. Instead, a goal is considered ready for achievement as soon as it is enabled and it has not been already achieved, marked as failed or released, or its super-goal has been achieved (Lines 7–10).

We finally added some regimented norms to ensure consistency in the treatment of raising and handling goals. Regimented norms in Moise are those norms that result in a failure if the norm preconditions are not holding when the norm is triggered. Such norms ensure that agents cannot perform undesired actions. Specifically, the newly introduced norms are needed in order to ensure that agents only raise and handle exception that follow the specification. They can be divided into three groups: (i) norms that govern when exception can be raised, (ii) norms that govern what agents can raise exceptions, and (iii) what shape raised exceptions need to have.

The first group of norms deals with the fact that agents should be prevented from marking as “failed” goals that are not enabled, yet. Similarly, we also impose that exceptions can only be raised when an exceptional situation actually occurs, and not arbitrarily by the agents. The norm in Listing 12 regiments a failure if an agent tries to mark as failed an goal which is not enabled.

Listing 12. NOPL norm regimenting goal failure.

The norm in Listing 13, in turn, ensures that fact $\mathsf{raised(E, Ag, Args)}$ is asserted into the state of the organization only when the condition of the corresponding notification policy holds. It is worth noting that we allow the condition not to hold if the raising goal has been already achieved by some agent (Line 5).

Listing 13. NOPL norm regimenting exception raising conditions.

The rationale is that, after a successful handling of the exception the critical condition will likely stop holding. Nonetheless, the fact $\mathsf{raised(E, Ag, Args)}$ , together with $\mathsf{done(S, RG, Ag)}$ , keeps track of the fact that an exceptional situation occurred (and has been handled). $\mathsf{done(S, G, Ag)}$ is a built-in NOPL dynamic fact that is added to the normative program to denote that agent $\mathsf{Ag}$ has achieved goal $\mathsf{G}$ in scheme $\mathsf{S}$ .

The second group of norms ensure that only the designated agents can raise exceptions. The norm in Listing 14 inhibits the raising of exceptions by agents not committed to the mission including the corresponding raising goal.

Listing 14. NOPL norm regulating agents allowed to raise exceptions.

Finally, the last group of norms checks that exceptions, that are raised, are compliant with the specification. This check is not trivial and requires a number of rules. First of all, since raising goals must produce an exception (which is a piece of knowledge), they can be marked as “achieved” only when the corresponding exception has been provided by the raising agent.

The norm in Listing 15 ensures that a raising goal is marked as ‘achieved’ only when the corresponding $\mathsf{raised(...)}$ fact has been asserted. More in detail, a raising goal $\mathsf{RG}$ is not marked as achieved in those cases when the fact $\mathsf{done(S, RG, Ag)}$ is added to the normative state but the related exception has not been raised (see Line 5), because the goal achievement operation fails.

Listing 15. NOPL norm regulating the achievement of raising goals.

Note that raising goals may be composite, encompassing multiple subgoals, just like standard organizational goals. In this case, before achieving the root goal, all subgoals must be completed. When a raising goal is composite and require multiple subtasks, we require that the exception is actually raised before marking the root goal as achieved (see Listing 15, Line 4).

The norm in Listing 16 ensures that exceptions can be raised only by following a well-defined report specification.

Listing 16. NOPL norm regimenting the raising of unknown exceptions.

Note that a fact of kind $\mathsf{raised(...)}$ can be asserted only when the right number of corresponding arguments has been asserted. Of course, each of them must comply with the expected format. This is verified by the norms in Listings 17–19. The one in Listing 17 ensures that the arguments of a $\mathsf{raised(E, Ag, Args)}$ predicate are ground predicates, i.e., they do not contain variables.

Listing 17. NOPL norm regimenting exception arguments groundness.

The norm in Listing 18 ensures that all the relevant information is provided, that is, that all the required arguments are instantiated.

Listing 18. NOPL norm regulating the absence of required exception arguments.

Like in Prolog, the NOPL construct $\mathsf{P= ..[F, T, A]}$ , used at Line 5, extracts the functor $\mathsf{F}$ , terms $\mathsf{T}$ , and eventually annotations $\mathsf{A}$ from a predicate $\mathsf{P}$ . The norm triggers a failure if at least one of the arguments specified for $\mathsf{E}$ does not unify with one of the terms in the list $\mathsf{Args}$ of dynamic fact $\mathsf{raised(E, Ag, Args)}$ . Indeed, this means that some of the information the agent was requested to provide is still missing.

The last norm, Listing 19 regiments the prohibition, for agents, to include undesired arguments when raising of an exception.

Listing 19. NOPL norm prohibiting undesired exception arguments.

The norm is triggered if an exception $\mathsf{E}$ is raised by some agent with a set of arguments $\mathsf{Args}$ and (at least) one of the arguments included in $\mathsf{Args}$ does not follow the specification for exception $\mathsf{E}$ (i.e., a corresponding $\mathsf{reportArgument(...)}$ fact is not present, see Lines 4–7). The result of all these norms is a failure in the exception raising action.

4. Related work

Exception handling has been addressed in several papers of the MAS literature with different perspectives and purposes. Current proposals, however, do not capture the roles of the exception raiser and handler as primitive elements, and hence either they do not scale up or they violate the agents’ autonomy.

Platon et al. (Platon, 2007; Platon et al., 2007b,a, 2008) look at exception handling as a tool that an individual agent can activate internally to preserve self-control despite the occurrence of exceptions. Jadescript (Petrosino et al., 2022, 2023) follows a similar approach. Here exceptions are special kinds of events that may occur internally to an agent and embody significant deviations from the nominal course of events (e.g., behavior failures). The language provides features to allow agents to detect and treat such kind of events. In contrast, our proposal considers exception handling as a social concern, addressed thanks to the cooperation of agents, which are assigned explicit (raising and handling) goals and can collaborate thanks to an unambiguous specification of exceptions.

A distributed perspective is taken by the guardian (Miller & Tripathi, 2004), a global entity that orchestrates the exception handling actions of a set of agents. When an exception is detected, the guardian applies a recovery rule that usually entails some exception handling procedures by the affected agents. In Klein and Dellarocas (1999), Dellarocas and Klein (2000), Klein and Dellarocas (2000), a decentralized evolution of the guardian model is proposed, where sentinels, equipped with handlers, may be plugged into the agents in case of an exception, in a coupled way. Sentinels communicate with agents using a predefined language for querying about exceptions and for describing exception resolution actions. Agents, for their part, are required to implement a minimal set of interfaces to report on their own behavior and modify their actions, according to the prescriptions given by the sentinels. Our proposal does not rely on special components such as sentinels or guardians, but seamlessly integrates exception handling into the agents themselves. However, the use of notification policies as specific constructs for specifying exceptions and their handling, allows a designer to keep separate the normal, expected behavior of an agent from its exceptional counterpart. This helps both the design and the maintenance of the agents themselves.

SARL (Rodriguez et al., 2014) is a general-purpose agent-oriented programming language and platform, which supports the notion of holonic multi-agent system (Gerber et al., 1999; Schillo & Fischer, 2002; Fischer et al., 2003). A multi-agent system in SARL is a collection of agents interacting together in a collection of shared distributed spaces. An agent may be equipped with one or more behaviors, which map a collection of perceptions represented by events to a sequence of actions. Recently, the authors introduced a specific kind of event that represents any failure that an agent could handle, if interested (SARL.io, 2023). Each time an agent needs to be notified about a failure (e.g., during the execution of its tasks), an occurrence of this event type is fired in the internal context of the agent, which may then handle it through some suitable behavior. One major limitation of the approach is that no explicit organization is set up for handling exceptions, In other words, no specific social structure is established among the agents, and hence, no mutual expectation about the handling of any failure event is possible (i.e., a failure event could pass uncaught legitimately). To overcome this issue, SARL spaces should be explicitly used to realize a social structure supporting exception handling as discussed in Baldoni et al. (2022, 2023b, 2025).

A drawback of the approach cited above is that no clear semantics is given to such a social structure. In Singh (2000), a social semantics for agent communication languages is presented. The work provides a foundational framework for understanding how agents exchange commitments and obligations during interactions, framing communication in terms of social relationships and norms. This aligns well with our approach to exception handling in MAS, where norms and obligations are central to defining how exceptions are raised and handled. Nonetheless, the approaches differs in scope. While we leverage the organization metaphor to provide the boundaries of the context where norms are defined, in Singh (2000) agents are peers that dynamically create commitments among each other as socially meaningful events that yield expectations on their behavior. Social commitments, indeed, are a valid conceptual tool to model responsibilities in MAS, also concerning the handling of exceptions. They are used, for instance, in Jain et al. (1999), where agents face exceptional interactions by adjusting their commitments at runtime (i.e., by possibly canceling and creating new commitments). In Kalia and Singh (2015), Mallya and Singh (2005) exceptions are modeled via commitment-based protocols. Exceptions amount to commitments being violated. The flexibility of commitments allows creating preference structures over runs, and also merging specific handling protocols inside runs. Anticipated exceptions, occurring during the execution of an interaction protocol (i.e., deviations from the normal flow that occur often enough and are part of the model), are dealt with by specifying a hierarchy of preferred runs. Preferences can, then, be used to define exceptional runs. Exception handlers are treated as runs just like protocols. Handlers can be spliced inside a given protocol when an exceptional run is detected. The approach also deals with non-anticipated exceptions (i.e., exceptions that are not part of the process model). Exception handlers, in this case, are constructed dynamically from a basic set of protocols. The approach, however, does not scale-up well, as the authors state, splicing exception handlers at runtime requires a search through a library of handlers, that can be computationally demanding. On the other hand, inducing a preference structure over runs requires considerable design-time effort and extensive domain specific knowledge.

Similar considerations can be made for Mandrake (Christie V et al., 2022) and Bungie (Christie et al., 2021), two approaches to realize fault-tolerant agent interaction. They exploit several patterns for extending information-based protocols so as to optimize the way in which missing messages are detected and resent. One major difference between these approaches and ours lies in the fact that (Christie et al., 2021; Christie V et al., 2022) focus on failures affecting the exchange of messages among the agents, whereas our approach focuses on exceptions affecting the achievement of organizational goals. This has a substantial impact on the way in which an exception is conceptualized and handled. Recently, proposals have been made (Baldoni et al., 2025a,b; Chopra et al., 2025) for integrating information protocols with Jason. This line of research may provide a good starting point for integrating also exception.

Exception handling in interaction protocols has also been considered in Gutierrez-Garcia et al. (2009), where both interaction protocols and exception handlers are modeled through obligations. Exceptions are seen as abnormal situations in which agents cannot release an obligation. The obligation is canceled and, similarly to Mallya and Singh (2005), a handler is sought for in a repository. Exception handlers are modeled in terms of new obligations to be issued. This approach differs from ours for two main reasons: (1) it is not framed in an organizational dimension and (2) exceptions are not first-class objects specified since the design phase, but are just as abnormal situations emerging during the enactment of an interaction protocol.

The treatment of exceptions is of interest also in the perspective of self-adaptive systems. For instance, the Rainbow architecture (Garlan et al., 2009) aims at facing unexpected events and provides mechanisms to monitoring a target system and its environment, detecting events that denote opportunities for adaptation, selecting a course of actions to address these opportunities, and apply changes. Once a problem is detected in the system (i.e., a violation of an architectural constraint), an adaptation strategy that suits the problem is selected and the framework coordinates the execution of that strategy. The approach bears some analogies with concept of notification policy in our proposal. However, the two approaches are substantially different in nature. In Garlan et al. (2009), the whole adaptation process is carried out by the components constituting the proposed architecture, that is, it is not part of the system at hand. In our approach, on the contrary, exception handling is embodied into the agents, leveraging their distributed nature. At the same tame, Rainbow does not take into account the autonomy of system’s components.

5. Discussion and conclusion

In this paper we have presented an exception handling mechanism for MAOs that is seamlessly integrated with organizational concepts, such as responsibilities, goals and norms. This allows us to exploit the normative system of an organization not only for coordinating the expected, correct, behavior of the system, but also the exceptional behaviors. Robustness and correctness are complementary concepts: while correctness is ‘the ability of software products to perform their exact tasks, as defined by their specification.’ (Meyer, 1988), robustness guarantees that if exceptional cases do arise, the system will terminate its execution cleanly. We have shown that, by introducing a proper infrastructure, both properties can be supported by the normative system uniformly. This makes the treatment of exceptions, from their raising to their handling, an integral part of a MAO model, enabling a systematic and homogeneous treatment of exceptions, and simplifying the implementation of the agents, as we have exemplified in JaCaMo. We see exception handling in distributed systems as having an intrinsically social nature. From a practical point of view, the social aspect is captured by means of notification policies that specify, at the design of the organization, anticipated exceptions and how these have to be treated by cooperating agents. Notification policies are, thus, a software engineering tool, supporting the construction of robust, loosely coupled distributed systems, and with high cohesive components. Low coupling is achieved by limiting the interaction between the raising and handling agents to the exception itself, whose structure is part of the organization specification. The raising agent does not even need to know who will handle the exception. On the other hand, high cohesion is promoted because the designer has the flexibility to ascribe the goals of raising and handling exceptions to the agents that have the right functionalities to accomplish them. As we have shown, these tasks can even amount to complex goals, whose sub-goals are distributed among many agents.

The treatment of exceptions presented in this paper has some similarities with that of accountability introduced in Baldoni et al. (2021, 2023a). In both cases, we allow a designer to complement the functional decomposition with additional social structures (i.e., notification policies and accountability agreements, respectively). The two concepts, however, are substantially different in scope. Exceptions, borrowed from Software Engineering, are suitable for treating perturbations anticipated at design time by activating predetermined handlers. Accountability, instead, defines feedback ‘channels’ that agents can exploit at runtime to get information of interest falling outside their reach, and then take actions. In this second case, the decision about whether to request for an account rests on the agent that in an accountability agreement plays the role of accountability taker (a-taker). That is, the interaction through accountability is not triggered by the occurrence of an exception, but from an internal decision taken by an a-taker agent. As a future direction of research we are currently working on designing a unified framework that will allow dealing both with exceptions and accountability.