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.