Using ondie() to diagnose runtime errors
The preferred method for handling runtime errors is using a
catch block; see also
Exception handling.
If you are not sure where the catch block is necessary, you can specify some logging in the ondie() action to help diagnose the problem and to alert other system modules that a problem occurred. For example:
action ondie() {
log "monitor instance terminating for " + myId;
route InternalError("Foo");
}
In some circumstances, you can move into a suspended or safe state, or initiate damage limitation activities, for example, such as pulling all active orders from the market. For example, Apama scenarios use the ondie() action to route an InstanceDied() event to a ScenarioService monitor. This in turn sends the event to connected clients so the termination of the instance can be handled, perhaps displayed, in a dashboard.
An alternative to using ondie() in this manner is to use a basic ACK, NACK, and timeout message exchange protocol so that a client is robust against its services being unavailable.
See
About executing ondie() actions for information about how
ondie() can optionally receive exception information if an instance dies due to an uncaught exception.