You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Valentin Mahrwald <vm...@googlemail.com> on 2010/03/31 07:58:46 UTC
Re: svn commit: r928178 - in /incubator/aries/trunk: blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/ blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/proxy/ blueprint/blueprint-testbundlea/src/main/java/org/apache/
Yes, that is intended :)
The new logic does the same as the old only a bit more efficient in
that every exception that is not an Error or a RuntimeException is a
declared exception.
There is one subtle difference though. A RuntimeException that is
declared in the throws clause of a method is still treated as a
RuntimeException and not a
declared Exception. This is similar to what EJB does and I believe
correct for our purposes (Joe Bohn also raised this as a bug
previously, ARIES 258).
Regards,
Valentin
On 30 Mar 2010, at 21:04, Lin Sun wrote:
>
> I noticed that this removed the previous checking of whether the ex is
> one of the method m declared exceptions. Method m is now not used at
> all in this postCallWithException. Is that intended?
Re: svn commit: r928178 - in /incubator/aries/trunk: blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/ blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/proxy/ blueprint/blueprint-testbundlea/src/main/java/org/apache/
Posted by Valentin Mahrwald <vm...@googlemail.com>.
As discussed yesterday this is a very valid point, the new code is
only equivalent to the old one if the exception passed into to the
interceptor
could actually have been thrown by the intercepted method. With the
current design of Collaborator though, it could have been a checked
Exception
that was thrown by another interceptor.
This points to a lack in the Blueprint Collaborator implementation. So
I will raise a bug against that
to make sure checked Exception thrown by interceptors are
appropriately converted into say UndeclaredThrowableExceptions before
being passed
to further interceptors.
Valentin
On 31 Mar 2010, at 14:17, Lin Sun wrote:
> Right the runtime exception was already handled before and the new
> code covers it too. :)
>
> I think it is reasonable to say that every exception that is not an
> Error or a RuntimeException is a declared exception, but I am not sure
> if it is a declared application exception. It may or may not, for
> example it could be an exception like SystemException from the
> transaction manager. IIUC, the previous code would not consider
> SystemException an application exception and set the rollback only on
> the transaction, while the new code won't.
> Lin
>
> On Wed, Mar 31, 2010 at 2:06 AM, Valentin Mahrwald
> <vm...@googlemail.com> wrote:
>>
>> On 31 Mar 2010, at 06:58, Valentin Mahrwald wrote:
>>
>>> Yes, that is intended :)
>>>
>>> The new logic does the same as the old only a bit more efficient
>>> in that
>>> every exception that is not an Error or a RuntimeException is a
>>> declared
>>> exception.
>>>
>>> There is one subtle difference though. A RuntimeException that is
>>> declared
>>> in the throws clause of a method is still treated as a
>>> RuntimeException and
>>> not a declared Exception. This is similar to what EJB does and I
>>> believe
>>> correct for our purposes (Joe Bohn also raised this as a bug
>>> previously,
>>> ARIES 258).
>>
>> Doh, shouldn't answer emails before breakfast. The RuntimeException
>> case was
>> already handled before, so the new code should in fact do exactly
>> the same
>> as the old code (except more efficiently).
>>
>>> Regards,
>>>
>>> Valentin
>>>
>>> On 30 Mar 2010, at 21:04, Lin Sun wrote:
>>>
>>>>
>>>> I noticed that this removed the previous checking of whether the
>>>> ex is
>>>> one of the method m declared exceptions. Method m is now not
>>>> used at
>>>> all in this postCallWithException. Is that intended?
>>>
>>
>>
Re: svn commit: r928178 - in /incubator/aries/trunk:
blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/
blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/proxy/
blueprint/blueprint-testbundlea/src/main/java/org/apache/
Posted by Lin Sun <li...@gmail.com>.
Right the runtime exception was already handled before and the new
code covers it too. :)
I think it is reasonable to say that every exception that is not an
Error or a RuntimeException is a declared exception, but I am not sure
if it is a declared application exception. It may or may not, for
example it could be an exception like SystemException from the
transaction manager. IIUC, the previous code would not consider
SystemException an application exception and set the rollback only on
the transaction, while the new code won't.
Lin
On Wed, Mar 31, 2010 at 2:06 AM, Valentin Mahrwald
<vm...@googlemail.com> wrote:
>
> On 31 Mar 2010, at 06:58, Valentin Mahrwald wrote:
>
>> Yes, that is intended :)
>>
>> The new logic does the same as the old only a bit more efficient in that
>> every exception that is not an Error or a RuntimeException is a declared
>> exception.
>>
>> There is one subtle difference though. A RuntimeException that is declared
>> in the throws clause of a method is still treated as a RuntimeException and
>> not a declared Exception. This is similar to what EJB does and I believe
>> correct for our purposes (Joe Bohn also raised this as a bug previously,
>> ARIES 258).
>
> Doh, shouldn't answer emails before breakfast. The RuntimeException case was
> already handled before, so the new code should in fact do exactly the same
> as the old code (except more efficiently).
>
>> Regards,
>>
>> Valentin
>>
>> On 30 Mar 2010, at 21:04, Lin Sun wrote:
>>
>>>
>>> I noticed that this removed the previous checking of whether the ex is
>>> one of the method m declared exceptions. Method m is now not used at
>>> all in this postCallWithException. Is that intended?
>>
>
>
Re: svn commit: r928178 - in /incubator/aries/trunk: blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/ blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/proxy/ blueprint/blueprint-testbundlea/src/main/java/org/apache/
Posted by Valentin Mahrwald <vm...@googlemail.com>.
On 31 Mar 2010, at 06:58, Valentin Mahrwald wrote:
> Yes, that is intended :)
>
> The new logic does the same as the old only a bit more efficient in
> that every exception that is not an Error or a RuntimeException is a
> declared exception.
>
> There is one subtle difference though. A RuntimeException that is
> declared in the throws clause of a method is still treated as a
> RuntimeException and not a declared Exception. This is similar to
> what EJB does and I believe correct for our purposes (Joe Bohn also
> raised this as a bug previously, ARIES 258).
Doh, shouldn't answer emails before breakfast. The RuntimeException
case was already handled before, so the new code should in fact do
exactly the same as the old code (except more efficiently).
> Regards,
>
> Valentin
>
> On 30 Mar 2010, at 21:04, Lin Sun wrote:
>
>>
>> I noticed that this removed the previous checking of whether the ex
>> is
>> one of the method m declared exceptions. Method m is now not used at
>> all in this postCallWithException. Is that intended?
>