#3 ApplicationException in Persistence Engine

[Gautam Jolly]

Invocation of the static domain object validations and
dynamic rules engine during Adds/Updates can
possibly throw application exceptions.
Currently, these excepions are wrappered inside
framework exception, which is displayed as an internal
error to the end-user.
It is desirable to prompt a more user-friendly error
message (which will be encapsulated in the application
exception).

The following 2 approaches can be used to handle
ApplicationException in the Persistence Engine.

A)
1- Add 2 methods to CustomException or
FrameworkException or UOWException - public
boolean hasApplicationException() and public
ApplicationException getApplicationException()
2- These methods will recursively check the source
exceptions to determine if any application exception
caused the error
3- Modify the preAdd, preUpdate, preDelete and
postLoad methods to throw ApplicationException
4- Fix the Tx in the Finder, Lookup, Viewer,
Maintenance patterns to handle the framework
exception appropriately, throwing the application
exception, if it caused the error

B)
1- Modify the signatures of add, update, delete, query
methods of UOW to throw ApplicationException (or
ApplicationExceptions ??)
2- Modify the preAdd, preUpdate, preDelete and
postLoad methods to throw ApplicationException (or
ApplicationExceptions ??)
3- Fix the Tx in the Finder, Lookup, Viewer,
Maintenance patterns to handle the new UOW
signatures

[Gautam Jolly]

Logged In: YES
user_id=544801

The following algorithm should be used for handling the
FrameworkException:
- If the cause is an ApplicationExceptions instance, then
simply throw that ApplicationExceptions instance.
- If the cause is an ApplicationException instance, then
throw that ApplicationException instance wrapped inside a
new ApplicationExceptions object.
- If the cause is another FrameworkException instance, then
throw that other FrameworkException instance.
- If the cause is any other Exception or if the cause is
null, then do not do anything.

A Tx method will then typically follow the pattern:
public OutputObject aTxMethod(InputObject input) throws
FrameworkException, ApplicationExceptions {
UOW uow = null;
try {
...
...
// invokes business code that can throw
FrameworkException or ApplicationExceptions
...
...
} catch (FrameworkException e) {
// Invoke the helper method to check the
FrameworkException for its cause
FrameworkException.throwCause(e);

// Just throw the FrameworkException, if the helper
method didn't throw any exception
// This will happen if the cause of the
FrameworkException is null or if its neither an instance of
ApplicationException(s) nor any other FrameworkException
throw e;
} finally {
if (uow != null)
uow.rollback();
}
}

In the dynamic proxy class of the persistence engine, the
InvocationTargetException also needs to be handled with care
so as to extract the correct error message.
It should invoke the soon-to-be-developed helper method
'public static void throwCause(InvocationTargetException e)
throws FrameworkException, ApplicationExceptions' method of
the FrameworkException class, for this purpose.

The following algorithm should be used for handling the
InvocationTargetException:
- If the cause is an ApplicationExceptions instance, then
simply throw that ApplicationExceptions instance.
- If the cause is an ApplicationException instance, then
throw that ApplicationException instance wrapped inside a
new ApplicationExceptions object.
- If the cause is a FrameworkException instance, then pass
it through the 'throwCause(FrameworkException e)' process.
- Repeat the above steps if the cause is another
InvocationTargetException instance.
- If the cause is any other Exception or if the cause is
null, then do not do anything.

ToDo

- Implement the helper methods 'throwCause()' in the
FrameworkException class
- Modify all the Tx pattern templates to use the helper method
- Modify the dynamice proxy class in the persistence engine
to use the helper method for handling InvocationTargetException