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? >> > >
