A good rule
of thumb is that each remote method on a logically defined tier should declare
that it throws just one exception (in addition to RemoteException):
a nesting exception that nests any of the exceptions that could be thrown
within that method's implementation. To reiterate a thought expressed earlier,
this methodology plays perfectly into interface-driven architecture: the
implementation-specific exceptions are abstracted into a singly defined
exception for some interface method.
I think this is the kind of
stuff we need right now – a set of exception handling principles to
adhere to going forward. I’d like to see us not stop everything to
go revisit our exception handling at this point – I’d prefer to
focus on functionality. Perhaps we can do a wholesale exception cleanup at the
start of one of our upcoming milestones.
Pawel, this is your area of
expertise. Could you provide us with a set of recommendations? Then we can
discuss as a group how to apply these across our architecture.
Thanks,
Joel
=00The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.