continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: refactoring the SCM
Date Wed, 07 May 2008 14:22:25 GMT
Ah... actually from memory I think they all throw ScmException, the  
others are there for "more information", but afaik they won't impact  
the contract.

- Brett

On 07/05/2008, at 11:19 AM, Rahul Thakur wrote:

>
> 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
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


Mime
View raw message