When an exception is thrown in an application, it may be caught within a try..catch construct or it may be allowed to filter up to the RIL.
The try..catch construct will typically handle the exception in one of the following ways:
An example of this is where the program must check for the existence of a record on the database. If the DAL throws a RecordNotFoundException, then this indicates that the record does not exist. This exception will not be allowed to reach the client, instead it controls how processing is done.
bPersonExists = true;
try {
dtls = myPerson.read(key);
}
catch(RecordNotFoundException rnfe) {
bPersonExists = false;
}
An example of this is a try..catch construct which is interested in only a specific exception. If any other exception is caught then it can be passed on upwards for some other handler to deal with.
try {
myPerson.checkCompleteness(dtls);
}
catch(curam.util.exception.AppException e) {
if(e.equals(APP.ID_INCOMPLETE_DATA)) {
// set this flag and continue
bIncompleteData = true;
} else {
// do not know how to handle this exception,
// pass it straight through.
throw e;
}
}
An example of this is where the handler would replace a generated DAL exception with an application exception containing a more user-friendly application-specific error message.
catch(RecordNotFoundException rnfe)
{
curam.util.exception.AppException e = new
AppException(APP.NO_SUCH_PERSON);
// substitute the message for the exception.
// (The new message includes the ID number of
// the record we searched for.)
e.arg(dtls.personIDNumber);
throw e;
}
An exception can be constructed with a pointer to another exception as follows:
catch(curam.util.exception.AppException
origException) {
curam.util.exception.AppException newException = new
AppException(MYAPP.ID_MYMESG, origException);
throw newException;
}
This has the effect of creating a linked list of exceptions with the most recent exception at the head of the list. This allows a detailed history of an exception to be built up for auditing or debugging purposes.