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
<[email protected]> 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?
