Effective handling of exceptional situations in robust software agents

1 Introduction

Agents and MASs (Multi-Agent Systems) provide a compelling approach to construct software systems intended to be sufficiently robust to effectively operate in open and dynamic environments. An agent can be designed to reactively deal with environmental changes and to proactively take actions to avoid exceptional situations. At the same time, several agents operating in concert in a MAS can effectively leverage techniques that further improve the desired level of robustness. All in all, the use of agents and MASs can effectively contribute to the construction of software systems that can better maintain their functionality even in exceptional situations. These situations are inevitable, and they may result from internal problems in an agent or from the challenges that agents need to face to achieve their objectives. Moreover, these situations can occur in a MAS because of the inherent coordination problems related to its social nature.

A broad range of software engineering methods and techniques can be adopted to handle exceptional situations. In particular, major programming languages provide dedicated features related to exceptions to effectively handle these situations. Note that the approaches used by programmers to concretely treat exceptions are generally grouped under the umbrella term of exception handling, while the programming language features that assist programmers in implementing exception handling are normally called exception handling mechanisms. Exception handling mechanisms are particularly relevant for AOP (Agent-Oriented Programming) languages (e.g., [37]) because these mechanisms cannot be limited to the ordinary mechanisms that mainstream programming languages normally provide. Actually, agents typically operate in open and dynamic environments, and the deviation from the nominal course of events in these environments should be considered as the norm rather than as an occasional case that deserves marginal interest (e.g., [25, 29]).

Jadescript [10] is a recent programming language intended to support the effective development of agents and MASs. It is an AOP language designed to promote readability, and therefore its syntax provides the linguistic constructs that are typically available in modern scripting languages like Python and JavaScript. Moreover, Jadescript features a set of agent-oriented constructs and related abstractions [9], which include agents, (agent) behaviours, and (communication) ontologies. Jadescript was designed to be closely linked with JADE (Java Agent DEvelopment framework) [3], hence its name. In particular, Jadescript agents operate in JADE containers [4], and they communicate, possibly with JADE agents, by asynchronously exchanging messages. The reception of messages is implemented in Jadescript by means of event handlers, which provide for event-driven programming using pattern matching [26]. Jadescript is an imperative language, and the code of agents can be organized and structured using the ordinary features of imperative languages, like procedures and functions.

The major contribution of this paper is to present three language features that were recently added to Jadescript to allow programmers to effectively represent and handle exceptions. These features were designed to meet five principal requirements, as follows. First, these features must be useful in helping programmers to represent exceptional situations, to effectively detect and prevent errors, and to program reactions to the unforeseen situations that occur in open and dynamic environments. Second, they must not reduce the intended readability of code because the advocacy of readability is one of the major design goals of Jadescript. Third, they must coherently integrate with the existing constructs of the language and, in particular, they must smoothly adopt the use of event handlers to provide for event-driven programming. Fourth, they must not severely affect the runtime performance of agents in the absence of exceptional situations. Finally, they must be restricted to the scope of each agent, so that they can be used by each agent to deal with the exceptional situations of its pertinence, even in solitude. Note that the extension of the presented language features, or possibly the addition of new features, to include the exceptional situations that can be approached only by considering the MAS as a whole are left for future improvements of the language. These improvements will provide Jadescript with a societal view of MASs, and they will also include coordination mechanisms, like roles and interaction protocols.

This paper is organized as follows. Section 2 provides a brief overview of related literature on exception handling mechanisms for agents and MASs. Section 3 discusses the new language features to handle the exceptional situations caused by internal errors in agents. Section 4 covers the new language features to account for failures in agent behaviours. Section 5 describes the new language features to deal with the exceptional situations that agents face in receiving messages. Section 6 discusses an example intended to concretely present the use of some of the new language features. Finally, Section 7 concludes this paper and outlines planned future developments of the language.

2 Related work

Exception handling is a traditional topic of software engineering, and classic papers on this topic are [16–18]. These papers primarily focus on structured exception handling for imperative programming languages. They essentially define exception conditions as specific situations that are detected during the execution of an operation and that the operation brings to the attention of the user.

Akka (e.g., [19]) is a toolkit that provides actor-based concurrency [21] and that advocates an interesting approach to exception handling. In Akka, the intended connection between an exceptional situation in an operation and the user of the operation is apparent. Actually, Akka proposes the supervision model to handle exception conditions in the actor model. When an actor A creates the actor B, A is said to be the supervisor of B and B is said to be the subordinate of A. Therefore, actors are organized in a hierarchy that is based on this dependency relationships among actors. Supervisors can create subordinates to request for the execution of sub-tasks and, in turn, handle their failures. When an actor fails, its supervisor is notified to gain the opportunity to handle the exception condition that caused the failure. The supervisor can then proceed by aborting, resuming, or restarting the execution of the subordinate. Alternatively, the supervisor can choose not to handle the failure in order to escalate it to its supervisor, if any. This approach to handle exception conditions is renowned for promoting the let it crash fault-tolerance model [36], in which actors are terminated to enable supervisors to retry operations.

SARL [35] proposes an exception handling mechanism similar to the exception handling mechanisms that mainstream OOP (Object-Oriented Programming) languages provide. This is possible primarily because SARL nicely combines the typical abstractions of agents and MASs with the ordinary abstractions of OOP. In SARL, exceptions are thrown by means of the usual throw statement, and they are handled with the try/catch/finally construct. Actually, SARL is based on a Java dialect called Xtend [11], and SARL agents are executed by a Java virtual machine. Therefore, the information about an exception condition is embedded in ordinary Java objects. In addition, SARL advocates a supervision model that is similar to the mechanism adopted by Akka. However, the mechanism that SARL proposes is based on the holonic nature of SARL agents. This mechanism relies on the capability of SARL agents to immediately communicate failure events to parent agents. Recently, [2] showed that an extension of SARL can achieve a sophisticated form of exception handling aimed at the MAS level. The approach that [2] proposes is based on the creation of social expectations regarding the handling of exceptions by agents. This extension of SARL can be implemented through the use of SARL spaces, which are shared blackboards that agents can use for mediated communication [7]. Agents can register as handlers or raisers for a specific type of exception in a dedicated SARL space. In the case of raisers, agents can also specify the type of event that causes the raise of an exception. In the same SARL space, raisers can then raise exceptions, which are represented by means of ordinary Java objects. Therefore, this dedicated SARL space provides raisers with a mechanism to notify handlers about exceptional situations, and it also facilitates the understanding among interested agents regarding the distribution of responsibility for exception handling.

A limitation of the supervision model of exception handling is that it reduces the autonomy of agents. To alleviate this limitation, [31–33] propose an exception handling mechanism designed to keep the autonomy of agents as an aspect of primary importance. This proposal is grounded on the idea that agents can take their own decisions, also concerning nominal and exceptional situations. On this premise, these papers claim that exceptions make sense inside agents [33], and therefore they propose an exception handling mechanism that is based on the exception-ready agent model. When an exception-ready agent operates in its environment, it stores an internal representation of the environment, which is used to define relevance and expectation filters. These filters are then used to evaluate the events generated by the environment and to classify them as normal or exceptional. Events tagged as exceptional are relevant but unexpected, and agents handle them as such.

Similarly, [39] argues that the supervisor model of exception handling does not provide a satisfactory approach for agents because agents are expected to encapsulate their own conducts. Therefore, [39] proposes an approach, which is implemented by the SaGE model for MadKit [20], that combines this argument with the idea that an exception handling mechanism integrated with the agent platform is necessary. This approach relies on considering agents as service providers and role takers, and it includes an exception handling mechanism that enables concerted exception handling at both the service level and the role level. Agents collaborate to deal with critical situations that are represented by exceptions signaled by invoked services or by agents with specific roles.

Jason [13, 14], the well-known AOP language based on the BDI (Belief-Desire-Intention) agent model, provides for the management of exceptional situations in plan execution by means of the plan failure mechanism. Actually, a Jason plan can always fail, and if a plan triggered by the goal +!g fails, then Jason puts the goal -!g on top of the same intention stack in order to cause the search for an alternative plan. This approach allows programmers to code robust agents because it allows an agent to attempt to reach its design goals using different courses of actions or creating new conditions for which the original plan is expected to succeed. The plan failure mechanism is limited to the conduct of a single agent because Jason does not provide a mechanism to let agents handle exceptions at the MAS level. However, JaCaMo [12], which is the MAS development suite composed of Jason, CArtAgO [34], and Moise [22], provides effective exception handling at the MAS level through responsibility distribution in agent organizations [1].

JADE, and consequently Jadescript, already offers effective means to represent exceptional and erroneous situations in a MAS. JADE and Jadescript offer multiple performatives that can be used to convey, using messages, the presence of exception conditions. In particular, an agent can signal that an unexpected or malformed message was received using a not_understood message. At the same time, failure messages can be used to signal failed attempts at performing actions. Note that the failed actions embedded in failure messages are considered feasible by the agent at the time it attempted to perform them. As a matter of fact, agents can always use refuse messages to signal that a requested action is not feasible, not supported, or not authorized. A message with refuse or failure performative always mentions both the action and a proposition that describes the reason for the refusal or the failure. Although Jadescript agents use all these performatives in their interactions, these performatives are also relevant to support basic operations of the agent platform. Actually, the AMS (Agent Management System) of a JADE platform provides crucial services, such as agent creation, through request messages. Therefore, in order to handle exceptions during the interactions with the AMS, every agent must be able to properly handle, at least, not_understood, failure, and refuse messages.

3 Exceptions in Jadescript

Jadescript descends from JADEL [5, 8], and therefore it is designed [6, 27] to provide for an effective translation to Java. JADEL was based on a dialect of Java, namely Xtend [11], which supports exceptions with the ordinary try/catch/finally construct. JADEL provided its exception handling mechanisms through Xtend, but the immediate inclusion of these mechanisms in Jadescript required an attentive selection that, ultimately, resulted in a deep redesign of these mechanisms, as follows.

First, it was decided not to include Java-like checked exceptions in Jadescript. These exceptions represent a good tool to increase robustness by preventing exceptions to occur without anticipation in the context of a method invocation. However, checked exceptions come with several drawbacks. For example, it is common opinion that checked exceptions tamper with modifiability because existing code cannot be easily updated to treat new exceptions. Moreover, checked exceptions force the explicit acknowledgment of exception conditions in the caller code, thus producing friction with extensibility and adaptability.

Second, it was decided not to include in Jadescript the try/catch/finally construct. This choice was taken because of the significant reduction of readability that this construct introduces. Actually, it may obfuscate control flow, increase the risk of resource leaks, and promote convoluted code. Moreover, this construct tends to be difficult to understand because its specification contains a large number of corner cases that programmers often overlook [40]. The constructs to support exception handling in Jadescript, as described in this section, do not use the try/catch/finally construct, and they blend well with the other constructs of the language. Most importantly, they preserve readability, which is coherent with one of the major design goals that guided the design of Jadescript.

The programmers that use Jadescript implement the details of their agents in terms of imperative code included in procedures, functions, and event handlers. This imperative code is structured in terms of sequences of operations that can fail. Examples of common operations that can fail are:

Division by zero;

The new exception handling mechanism uses propositions to meet the first requirement, which regards a way to effectively represent exception conditions. This design choice is particularly fit for Jadescript because Jadescript already provides propositions to describe facts about the world, and therefore propositions can be used to describe exception conditions. In particular, for built-in exceptions and errors, the corresponding propositions and predicates are predefined in the provided basic ontology [9]. Similarly, for application-specific exception conditions, programmers can use propositions and predicates in their application-specific ontologies.

The new throw statement was added to Jadescript to meet the second requirement, which regards the need to notify the occurrence of exception conditions. As in other imperative languages, the statement is introduced by the throw keyword, and it requires an expression. In Jadescript, this expression must evaluate to a proposition, which is intended to describe the details of the exception condition.

Finally, exception handlers were added to Jadescript to meet the third requirement, which regards the need to detect the occurrence of exception conditions. Several occurrences of this type of handler can be added to the body of an agent or to the body of a behaviour. By default, an exception handler captures all kinds of exceptions, but several constraints can be added to the head of the handler to restrict the set of captured exceptions. As for message handlers, the constraints on captured exceptions can be expressed in two ways, which can be combined. The first way, called when-expression [9], declares constraints written as Boolean expressions that can include values extracted from the exception and from the state of the agent or behaviour. Note that when-expressions must be composed of operations without side effects, and this requirement is checked at compile-time. The second way, called pattern matching, is already available for message handlers [26], and it can be used to easily declare the type and the structure of the propositions that describe captured exceptions, thus destructuring propositions in parts. The proposition describing the exception condition can be accessed in handlers and in when-expressions by means of the exception keyword. When multiple exception handlers are defined in the same behaviour declaration or agent declaration, the handler to be executed is selected by attempting to match the exception against the pattern (if available) and the when-expression (if available) of each exception handler. The search continues until a handler matches successfully, but when no applicable handlers can be found, the exception escalates. An exception escalation results in two different outcomes, depending on the context. If the exception escalates from the code of an agent, the agent shuts down after emitting an appropriate message to the log and properly deregistering from the platform. Conversely, when the exception escalates from the code of a behaviour, the behaviour fails, as discussed in next section. Figure 1 shows a flowchart of this exception handling mechanism.

OPEN IN VIEWER

Fig. 1

Flowchart of the Jadescript exception handling mechanism.

In Jadescript and in JADE, (agent) behaviours are the main components of the layered architecture of the agents. They are executed concurrently by the agent, and they are used to model the tasks that are performed by the agent. The operations that compose behaviours can fail for several reasons, like the ones mentioned in Section 3. Moreover, some scenarios can benefit from the explicit signaling of the failure of a behaviour as part of the design of the agent. Note that a well-designed behaviour can fail even if no operations threw an exception. For example, a behaviour can detect, during its execution, that the requested task can no longer be completed. In these cases, the failure of the behaviour correctly expresses the idea that some conditions prevent the task to be successfully accomplished.

The fact that a task can no longer be accomplished can only be partially captured by the throwing of an exception. Actually, throwing an exception simply indicates that, during the execution of a task, some conditions that require further attention are met. Instead, the failure of a behaviour brings an additional negative information, which is related to the fact that the task can no longer be accomplished. Moreover, the exceptions of ordinary imperative languages always happen in a context in which a hierarchy of operations defined by the caller-called relationships is in place. Therefore, when an exception occurs, a responsibility chain can be computed by navigating the call stack backward. Active behaviours do not enjoy this hierarchical structure, because, even if a behaviour can create and activate another behaviour, both behaviours continue to execute concurrently in the agent. In addition, any behaviour can be deactivated and reactivated by a different behaviour. For these reasons, an exception handling mechanism ultimately designed around the idea of behaviour failure is expected to fit well for the peculiarities of the behaviours of Jadescript agents. This new mechanism encompasses two ways to cause the failure of a behaviour. In the first, an unhandled exception escalates from a behaviour, while in the second the fail statement is used for a specific behaviour. Section 3 describes how an exception can cause a behaviour to fail in the first case. Instead, to explicitly cause a behaviour to fail, programmers can use the fail statement, as follows.

The fail statement requires two arguments, which are provided as expressions. The first argument, which follows the fail keyword, is the behaviour that is failing. The second argument, introduced by the for keyword, is a proposition that represents the reason for the failure of the behaviour. Note that in the case of an escalated exception, the proposition describing the exception condition is automatically used as the reason for the failure. Moreover, note that the expression evaluating to the failing behaviour can refer to any behaviour, which can be used to design behaviours that can cause the failure of other behaviours.

When a behaviour fails, it is automatically deactivated, and an appropriate behaviour failure handler is executed, if available. Behaviour failure handlers are similar to exception handlers. Their heads support the specification of patterns that can possibly match the propositions that describe the reasons for the failures. Moreover, they have a special behaviour variable that can be accessed within when-expressions and that can be matched against behaviour patterns. Behaviour patterns are a novel addition to the language. They match against behaviours, and they are composed of two parts. The first part is a name that unifies with the behaviour, and the second, which is separated from the first by the as keyword, is the expected behaviour type [28]. Both parts can be replaced with underscores to include placeholders that allow any value or any type to match. The search for a matching handler is done by checking all available handlers, from the top of the agent declaration to its bottom, until a matching handler is found. Figure 2 shows a flowchart that describes how behaviour failure handlers are selected.

OPEN IN VIEWER

Fig. 2

Flowchart of how behaviour failure handlers are selected.

Jadescript agents schedule active behaviours using a non-preemptive scheduling algorithm. The active behaviours share the internal state of the agent and its message inbox. The message inbox is a queue that contains all the messages received by the agent and still awaiting to be handled. Every time a behaviour is scheduled, all the headers of its message handlers are checked against the messages that are still in the inbox. This is useful to determine to which incoming message a behaviour should react. However, if a message does not match against the constraints of a handler, the message is kept in the inbox at its current position to ensure that another handler, potentially in another behaviour, can successfully handle it. When no handlers in any of the active behaviours successfully match against a message in the inbox, the message does not get extracted, and therefore it remains in the inbox, potentially for an indefinite period. These stale messages are problematic for the execution of the agent because in JADE, and therefore in Jadescript, the inbox is a queue with limited capacity, and when full, the oldest messages are simply discarded. However, this mechanism can potentially cause agents to ignore relevant messages. Actually, agents are normally requested to properly react to stale messages because, when ignored, these messages can potentially prevent the identification of interesting situations.

When the agent has only one behaviour, the processing of stale messages can be easily accomplished by simply writing a message handler at the end of the behaviour body, with no constraints on handled messages. The body of this handler can define how the agent reacts to the messages that do not match against the constraints of the other message handlers. However, this approach is perfectly valid for agents with just one active behaviour, but it is problematic for agents with several active behaviours [29].

Actually, the problem of handing stale messages when agents have multiple active behaviours is not easy to solve without specific language facilities because the identification of a behaviour intended to check which messages are of interest for other active behaviours is not a viable approach. To deal with these kinds of problems, two new features have been recently added to Jadescript. The first feature is represented by the new stale message handler, which extracts stale messages from the inbox and handles them. To this purpose, a stale message is precisely defined as a message that did not match against any message handler after all active behaviours have been scheduled at least once after its reception. The second feature that has been recently introduced in Jadescript is the put back statement, which enables a fine-grained control of the message inbox. This statement accepts a message as argument right after the put back keywords and, when executed, it puts its argument in the message inbox, in front of all other messages. Note that any message can be used with the put back statement, even when the message has been recently removed from the inbox.

The default conduct of Jadescript agents in the presence of stale messages has been also changed to effectively benefit from the two recent features of the language. When no stale message handler is defined in an agent or in any of its active behaviours, the agent now automatically extracts stale messages, and it handles them in the following way:

If the stale message is a not_understood message, the agent writes a message to its log to signal the problem; and

OPEN IN VIEWER

Fig. 3

Flowchart of how Jadescript agents process stale message.

In the example described in this section, a set of agents engage in the contract net interaction protocol [15, 38]. During the execution of the protocol, these agents coordinate and reach an agreement on the task of streaming musical tracks for the user, for which the protocol initiator, implemented by a StreamCnetInitiator agent, acts as mediator. Several protocol participants, implemented by StreamProvider agents, are active in the MAS, and their identities are known to the initiator. Each participant has a database of musical tracks available for streaming, and it can offer available tracks at various streaming quality levels (bitrates) and prices. The initiator has the goal to provide its user with a stream for a specific track, and it selects, among the proposals submitted by the participants, the best proposal according to the preferences of its user. Moreover, the initiator is provided with a set of user requirements that describe non-negotiable constraints on the price (maxPrice) and the quality (minBitrate and maxBitrate). Note that the main purpose of this example is to discuss several occurrences of exception conditions that can arise during the enactment of the protocol. Therefore, several details on agents and behaviours are not discussed for the sake of brevity.

As soon as the initiator starts, it immediately engages in an iteration of the protocol by sending calls for proposals to all participants. Right before sending these messages, the initiator arranges to handle responses with the activation of a CollectProposal behaviour. Then, it schedules the subsequent phase of the protocol with the postponed activation of an EvaluateProposals behaviour. These behaviours are activated by an InitiateCnet behaviour, which is used to start a new iteration of the protocol. The initiator handles the reception of proposals in its CollectProposals behaviour, which is shown in Figure 4. Two message handlers extract propose and refuse messages from the inbox of the initiator. The message handler for propose messages extracts each message containing a proposal, destructuring the proposal into stream and conditions. Then, the validateProposal procedure, which is defined in the agent, is used.

OPEN IN VIEWER

Fig. 4

The initiator of the contract net protocol uses the CollectProposals behaviour to handle proposals and refusals from participants.

This procedure first checks if the proposal belongs to the current iteration of the protocol by ensuring that the token of the proposed Stream action equals the currentToken property of the agent. If the two tokens do not match, then the proposal is a late message from a previous iteration of the protocol, and an exception, namely TokenMismatchException, is thrown. The validateProposal procedure then checks if the proposed track matches the requested one. The requested track is stored in the track property of the agent, and the procedure throws an exception, namely InvalidTrackException, if the proposed track does not equal the requested track. Finally, the procedure compares the proposed price and quality with minPrice, minBitrate, and maxBitrate, which are stored as properties of the initiator and were sent to participants in the initial call for proposal. When the received proposal does not satisfy the requirements, an exception, namely InvalidConditionException, is thrown. This exception includes three values: the message containing the invalid proposal, the precondition that was not met, and the specific condition that invalidated the proposal. If the proposal is considered valid, no exception is thrown, and the message handler uses the addProposalSorted procedure to save the proposal. Each proposal is internally represented as a triple, namely the negotiated Stream action, the ProviderConditions, and the agent identifier of the participant that made the proposal. As the name suggests, the addProposalSorted procedure ensures that the collected proposals are sorted according to the preferences of the user. Finally, note that the CollectProposals behaviour includes three exception handlers. These handlers ensure that when an invalid proposal is submitted to the initiator, the behaviour does not fail, instead it correctly continues to collect proposals from other participants. Moreover, all exception handlers suitably handle invalid proposals by replying with a reject message, which provides detailed reasons for the rejection.

At the deadline, the EvaluateProposals behaviour, shown in Figure 5, is executed. The behaviour is initialized with the set of CollectProposals behaviours, namely collect, which is used to deactivate the behaviours and to retrieve the collected proposals. These tasks are performed at the activation of the behaviour. If no valid proposals were submitted to the initiator after the deadline, the task represented by the EvaluateProposals behaviour cannot be completed. Therefore, the EvaluateProposals behaviour fails using the NoProposals proposition as the reason for the failure. If at least one valid proposal was received, the behaviour extracts the best one, which is contained in the first element of the sorted list of collected behaviours, and it sends the consequent messages. In particular, the initiator accepts the proposal of the participant that provided the best proposal, and it rejects the proposals of the other participants. At the same time, the initiator arranges to receive the stream of the accepted proposal by activating the AwaitResult behaviour. Moreover, it performs the delayed activation [30] of a second behaviour, namely ResultTimeout, intended to possibly discard the AwaitResult behaviour after a timeout. Figure 6 shows the ResultTimeout behaviour, which is used to cause the failure of the corresponding AwaitResult behaviour, if still active. Note that this behaviour uses the fail statement to cause the failure of another behaviour.

OPEN IN VIEWER

Fig. 5

The initiator of the contract net protocol uses the EvaluateProposals behaviour to select the best among received proposals.

OPEN IN VIEWER

Fig. 6

The initiator of the contract net protocol uses the ResultTimeout behaviour to ensure that a requested stream is not waited excessively.

The StreamCnetInitiator agent includes several behaviour failure handlers. Each handler is associated with a different phase of the protocol, and it reacts to a specific cause of failure. In particular, if the InitiateCnet behaviour fails, then there was a problem in the initialization of the protocol, and therefore the agent shuts down. Instead, if CollectProposals fails, the protocol was correctly initiated, and therefore its interruption calls for the immediate abort of the current iteration of the protocol [15]. Moreover, if the EvaluateProposals behaviour has no proposals, the initiator generates a new currentToken, and it restarts the protocol after a short delay. Finally, a behaviour failure might occur while awaiting for the stream mentioned in the selected proposal because, for example, the timeout for receiving the beginning of the stream has occurred. In this case, the initiator requests to cancel the streaming, and then it restarts the protocol in the attempt to eventually obtain a valid stream.

As mentioned above, the initiator can reattempt to enact the protocol in case of failure. In this case, it increments its currentToken property to uniquely identify the new iteration of the protocol. However, a slow participant might provide a late proposal, which can be identified because it refers to a token that does not equal currentToken. The LateProposals behaviour takes care of those proposals using a stale message handler. The handler first checks if the token of the proposal equals currentToken. If it does, then the message is a proposal that belongs to the current iteration of the protocol, and therefore, it is put back in the message inbox using the put back statement. Otherwise, the proposal is considered as late, and therefore it is rejected by sending a reject proposal message that details the reason for the decision.

This paper presented a set of language features that were recently added to Jadescript. These features were designed to help programmers represent, detect, and manage the exceptional situations that agents often need to face. These features required the addition of selected language constructs to meet some design criteria. For example, these new constructs must smoothly integrate with the language, they must provide for event-driven programming, and they must not severely affect the performance of the agents in nominal cases. The result of the introduction of these new language constructs is that programmers can now manage exceptions in Jadescript by representing them in terms of propositions and by using dedicated exception handlers to treat them. Moreover, programmers can now use a dedicated behaviour failure mechanism to react to the failures of behaviours. Finally, they can also specify adequate reactions to the reception of unexpected messages. All in all, the new features that Jadescript now provides can effectively assist programmers in detecting and handling exceptional situations, thus achieving the level of robustness required by most of the relevant application scenarios envisaged for software agents (e.g., [23, 24]).

In the future, Jadescript will be further extended to include a dedicated support for interaction protocols in order to promote interoperability among agents in open and dynamic environments. The addition of a dedicated support for interaction protocols in the language will open new opportunities to extend the discussed support for exception handling. For example, the adoption of interaction protocols will enable Jadescript to adopt the exception-ready agent model [33], or a variant of it. In this model, agents use messages in the intent to change the mental states of the other agents. A sender agent acts on the mental states of the receiver agents using an internal representation of these states. This internal representation can be abstracted from the current state of the conversation regulated by the adopted interaction protocol, and it can be automatically updated after each message is sent or received. Therefore, a relevance filter and an expectation filter can be specified to automatically classify received messages as normal or exceptional.

The inclusion of a dedicated support for interaction protocols in Jadescript can also open additional possibilities regarding the identification and the reaction to exceptional situations when these situations regard the MAS as a whole. For example, interaction protocols can be used to build stable social structures among agents in order to distribute the responsibilities of exception handling among the agents enacting the protocol, as suggested in [1, 2].

Finally, it is worth noting that the inclusion of a dedicated support for interaction protocols in Jadescript would benefit from an extension of the support for behaviours. Actually, Jadescript now supports only two types of behaviours, namely one-shot and cyclic behaviours [9]. These two types of behaviours are typically considered sufficient to organize the tasks of the agents. However, behaviours could benefit from a higher degree of reusability if Jadescript could support the composite behaviours that JADE already provides [4]. In JADE, these behaviours are defined by embedding other behaviours, called their child behaviours [4]. Child behaviours are then executed with specific scheduling strategies, for example, sequentially, in parallel, or using a finite-state machine, that depend on the type of the composite behaviour. The extension of Jadescript to include composite behaviours can add an effective support for the description of interaction protocols as finite-state machines, which is the approach that JADE already uses to provide an effective support for interaction protocols. Moreover, the construction of explicit hierarchical organizations of behaviors can enhance the proposed mechanism to handle behavior failures. When a child behavior fails, a behavior failure handler defined in the parent composite behavior can handle it, and the hierarchy tree can be traversed upward until the agent is possibly reached to ultimately handle the exceptional situation.