JOSIF Main Page | JOSIF Guidebook | Modeling | General Patterns | Exceptions

There are two types of common exceptions defined in the Interface Framework, i.e., predefined common exceptions and optional common exceptions.

• The predefined common exceptions are automatically inserted into all operations, with the exception of one-way operations which do not have exceptions at all. These exceptions are listed in Internal Framework Model#Pre-defined Exceptions.
• The optional common exceptions are used as needed for a given operation. They must be explicitly added to an operation. These exceptions are listed inCommon Framework Model#Common Exceptions.

Interface developers should try as much as possible to reuse these common exceptions rather than creating new ones.

Every common exception contains an “error reason” parameter of type String that may be used to supply more information (See details in Internal Framework Model#Pre-defined Exceptions). This information should contain the specific condition(s) that have resulted in the exception as defined in the description part of the associated Use Cases.

Exception Hierarchy

The following figure shows the predefined exceptions and their hierarchy relationship, where the hierarchy goes from general (at the top) to more specific (moving towards the bottom). The distinction is made between exceptions that are caused by the server (server-side issue) and exceptions that are essentially the fault of the requesting system (client-side issues).
700px

The server system, i.e., the system that generates the exception, should use the most specific exception that it can determine. So, for example, theUnableToComply exception (general) would only be used if the server cannot determine a more appropriate (specific, detailed) exception such asCommunicationLoss.

The following figure shows the optional exceptions and their hierarchy relationship, where the hierarchy goes from general (at the top) to more specific (moving towards the bottom). The distinction is made between exceptions that are caused by the server (server-side issue) and exceptions that are essentially the fault of the requesting system (client-side issues).
700px

2 remarks on this figure:

• In some cases, an optional common exception is related to one of the predefined common exceptions. In those cases, the related predefined common exception is also shown (in green).
• NotInValidState and ObjectInUse cannot be classified as caused strictly by client- or server-side. For example, another client might be using an object instance when a client tries to manage the same object instance. This is more of a race condition as opposed to an exception caused by either the client or the server.