The motivation behind this was that layer/module should (ideally) expose
limited number of granular exception(s). Having said that, I agree
wrapping-unwrapping exceptions can get clunky and contract definition
should be merited by the exception handling instances that we have
observed in the code.
I wasn't referring to nesting exceptions (may be wrong use of 'wrap'),
but unifying the hierarchy of ScmExceptions, so clients can introspect
using 'instanceof' to determine specific ones.
Rahul
Brett Porter wrote:
On 07/05/2008, at 10:27 AM, Rahul Thakur wrote:
Cool! :)
Just one note on exceptions - Can we wrap up all the SCM exceptions
under one parent which is then exposed through the ContinuumScm API?
Clients that need to do any special handling can introspect the
extension.
WDYT?
One of the problems in the code that was just removed was that some
exceptions were getting swallowed or handled in the wrong place because
it was trying to introspect a nested exception.
I don't really think wrapping an exception without adding any
information, only to unwrap it later makes much sense.
I think the caller should be able to deal with the Maven SCM exceptions,
and the IOException resulting from passing a bad working directory.
On the other hand, we don't really want to change interfaces in the
future, and a wrapped exception does provide that flexibility like the
request parameter does.
What do others think?
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
