...

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.