Exception chaining

[HS Thomas]

Some previous posts of people who have passed this cert have mentioned this design feature ?
Can anyone throw some light on what is meant by this, and give a simple example.
Would including this result in additional marks?

I think the addition of cause (which can be any Exception thrown by any methods that create a new BookingException), describes the feature roughly

 class BookingException extends Exception {    public BookingException(String msg, Throwable cause) {        
super(msg, cause);    }  

but then that info could have been contained in msg.
regards
[ January 16, 2003: Message edited by: Mark Spritzler ]

[HS Thomas]

i.e I'm not sure where chaining occurs.

[Mark Spritzler]

In Java 1.4 they include Exception Chaining. Basically what this is how it works.
Class A has an Exception, say an IOException, this is thrown to a calling method in Class B, now Class B catches this Exception and throws another Exception of a different Exception type, say DatabaseException. Class C which called the method in Class B, now catches the exception and handles it.
Now in earlier Java releases Class C would only have the DatabaseException to work with, and then it wouldn't know that the original exception was an IOException. With Exception Chaining, the Exception that Class C receives has references to the Original Exception object. Hence the name Chain. So you can use this reference to get details of that Original Exception.
These chains of Exceptions can be as long as it needs to be.
Say I get a DatabaseException which has a reference to a ServerException, which has a reference to a RemoteException, which has a reference to a InvalidNumberException. You class has the DatabaseException and way to travers all the way down to the InvalidNumberException and see what is inside it.
Does this make sense? For those that have more experience with Exception Chaining, did I miss something or say it completely wrong?
Mark

[HS Thomas]

Mark,
That was explained really well. The chaining comes across clearly, much better than some web pages I've looked at since.
So using chaining , a printStackTrace gives a much better trace.
Also , a catch mid-way could handle errors differently depending on the type of Exception.
Thanks.

[Juan Ec]

i used in my submission (for 1.3) this technique plus some enhancements for the exception handling and the score was ok

[Lasse Koskela]

How did you guys handle the exceptions with regard to different levels of client-side (gui vs facade)? I mean on what level, what kind of information getMessage() returned for each level exceptions, etc.?

[Juan Ec]

in my design each subsystem throwed just exceptions congruent with its level. as example
my (layered) database subsystem throwed
database exceptions at a medium level, while my client facade just throwed client exceptions in an upper level. for this purpose i extensively used translations & exception chaining.

[Lasse Koskela]

Originally posted by Jaun Katabasis:
in my design each subsystem throwed just exceptions congruent with its level. as example
my (layered) database subsystem throwed
database exceptions at a medium level, while my client facade just throwed client exceptions in an upper level. for this purpose i extensively used translations & exception chaining.

In other words, at level 1, for example, you caught an IOException, wrapped it into a DatabaseException and threw it to level 2, which in turn wrapped the DatabaseException into a BookingException and threw it to the highest level (GUI?), which in turn acted on the BookingException by displaying a popup saying "Booking failed". Was I even close?

[HS Thomas]

quoted by Mark Spritzler :
Say I get a DatabaseException which has a reference to a ServerException, which has a reference to a RemoteException, which has a reference to a InvalidNumberException. You class has the DatabaseException and way to travers all the way down to the InvalidNumberException and see what is inside it.

Also considering the previous posts by Lasse and Jaun:
I was wondering how this would work given that the Data class is re-usable for other tables,
the Connection class is also re-usable for other tables ?
Say, if a DatabaseException is thrown with a string of Chained Exceptions within it , a RemoteException will be thrown at the Connection level .
But since a RemoteException can be caused by any number of Exceptions not just DatabaseException , at the Connection level we ought to catch RemoteException and throw new ConnectionException(msg,RemoteException) which will be caught at the GUI level by Booking (or Payment) method , wrapped into a BookingException (or PaymentException ) - useful to know what the user was doing - and handled accordingly.
Any thoughts on this, I am just guessing here.
[ January 21, 2003: Message edited by: HS Thomas ]
[ January 22, 2003: Message edited by: HS Thomas ]

[Juan Ec]

that's the point
the class that finally manages the exception just have to deal with one kind of exception, say ClientException, but it can be explored to know the real origin of the error.
if you just make exception propagations you will not need chaining, but the class that finally manages the exception will have to deal with different kind of exceptions, from different levels. a chaotic design imo.
if you decide to design the exceptions to be throwed at proper levels - DatabaseException at database subsystem, ConnectionException at connection subsystem, etc - , you will have to translate exceptions, turning - say - the RemoteException into a ConnectionException, this one into a DatabaseException and this one into a ClientException. if you don�t use chaining your final ClientException will have no information at all on the real problem. chaining will let you translate exceptions in the subsystems without loosing information.
in my submission i used a special help dialog to exploit this hability plus a little enhancement that let me show a final error message to the user as a composition of the error message on the top chain and other message (usually the one of the lower chain). a ' see details ' button shows when clicked the complete chain to provide more information on the error (not available if there is just one exception in the chain). so i offered a simply but informative message, and the possibility to check the errors with more detail.
all this for 1.3, as 1.4 exception provides already chaining capabilities
sorry for my poor english. hope that helps

[HS Thomas]

the class that finally manages the exception will have to deal with different kind of exceptions, from different levels. a chaotic design imo.

This has always previously been a stumbling block for me.
BTW, I'd rate your English as very good, and it is content that matters.
Thanks for your excellent response.
I am used to sites that just wrap and throw a generic Exception , say FBNException and the client catches it and does a printStackTrace.
Just another question , while wrapping at each level is it possible to supply Diagnostic Information in the message ?
Say , for instance , that a RemoteException is caught at the Connection level. How does the application know that this is the level where the source of the problem lies in order to supply Diagnostic Information in the message?
Interrogate the RemoteException and if there are no deeper levels , supply the Connection level args for the method throwing the RemoteException ? Is there a standard procedure to follow ? Perhaps JUnit has a test switch that can be turned on.
Many a time I'd have to walk over to users to ask them what on earth did they do ! I may not have that luxury next time. More often than not it occured ages ago and they had forgotten , so it was deferred to other Test Cycles !
regards
[ January 22, 2003: Message edited by: HS Thomas ]

[Juan Ec]

thanks Thomas, i always think my technical english is not good enough

while wrapping at each level is it possible to supply Diagnostic Information in the message ?

of course. it is up to you to design your custom exceptions with members to store information on the error context when you throw them.
if (temperature > 100){
throw new TemperatureException(temperature, currentTime,boilerID);
}
but keep in mind your exceptions will need to be able to mantain that information stored in the first member of the chain, among all the chain, so that the last one can recover that context information for processing.

How does the application know that this is the level where the source of the problem lies in order to supply Diagnostic Information in the message?

the source of the error can always be identified by the first member of the chain, so the parts of the system where new exceptions are thrown and originate a new chain (not were you just make translations) are the ones where you should provide that additional information. if the first exception is not a customized one (as example, a RemoteException), you always can translate it to a customized one that can store the information you need.
chaining is a flexible and simple technique, take care not to add more complexity than needed
[ January 22, 2003: Message edited by: Jaun Katabasis ]

[HS Thomas]

What have we unleashed ?
You actually make all this technical stuff sound exciting. I don't see any problem with your technical writing either!
More of the same, please ! I don't recognise your name and I've been watching this forum for a while.
Please keep posting!
Back to Work, - point taken about keeping it Simple.
Perhaps I'd allow myself a couple of custom Exceptions. I'll just wait and see what bugs me most.
Thanks for sharing the info, Jaun.
[ January 22, 2003: Message edited by: HS Thomas ]