Catching Errors

If an error occurs, the default behavior is that the service execution stops at this point, and an error message is sent back. You can change that behavior by catching the error in your activity diagram.

There are fatal and non-fatal errors.

Fatal errors cannot be caught. Depending on where the fatal error occurs, these errors are not sent back to the client - they are written to the log file of the xUML service. For example, if an xUML service starts up and cannot find needed add-ons, this error is logged and the service shuts down.
A list of fatal errors can be found at Log Errors.
You can catch non-fatal errors by using domain and code values. These values are listed on System Errors.

You can catch system errors in the outgoing flow of a decision. Define a catch statement as a guard expression, and supply error domain and code as listed on System Errors. Besides using exact code values like 12, it is also possible to use a wildcard (*) for all errors of the specified type. Such an example is shown in the following activity diagram.

MemoryAdapter_GuessingGame_Example

Click here to download a simple example model that shows the usage of the Memory adapter in Scheer PAS Designer.

In mentioned example, the operation gameRunning() calls the retrieve() operation of the Memory Adapter to check if there has been data stored to memory at all (errorCode="*"). If not (error case), the operation returns false, else the operation returns true.

It is also possible to use variables and provide the error code dynamically.

Syntax	`catch errorCode = aString errorType aString` `catch errorCode = aLiteral errorType aLiteral`
Semantics	Catches an error that occurred in the previous action. `catch` must be applied on a decision branch.
Substitutables	`aString`	A string variable containing an error code (errorCode) or an error domain (errorType).
Substitutables	`aLiteral`	A string literal containing an error code (errorCode) or an error domain (errorType). `*` is a special literal representing any error code or domain.
Examples	Catch any errors of the `MEMADSM` error domain. CODE `catch errorCode = '*' errorType = 'MEMADSM'`

Where Errors Need to be Caught

An error can be caught

either immediately after the action node that throws the error (for instance a MongoDB adapter action),
or directly after the operation call containing the erroneous action node.

In the latter case, within the activity diagram that implements the operation, any activity step after the error has occurred is not executed. As a rule, if the error is not caught in the activity diagram, the Runtime passes the error to the caller (the calling sub-activity). However, in order to catch the error, the decision needs to be placed directly after the operation call.

Accessing Error Objects

Errors that are caught can be accessed by using the error functions getError() and getErrors(). Both functions return one resp. multiple object(s) of type Error.

CODE

{
	"callstack": ["Callstack"],
	"category": "String",
	"code": "String",
	"description": "String".
	"detail": "Any",
	"domain": "String",
	"response": "Blob",
	"timestamp": "DateTime"
}

The error object contains information on the callstack, some more error details, response information (e.g. from a REST call), and an error timestamp.

Where Errors Need to be Caught

Accessing Error Objects

Related Content