Hi Joshua, It is a philosophical choice more than anything. The open-source framework landscape in general seems to be moving towards RuntimeException hierarchies for framework code. Take Hibernate for example - in Hibernate 2.x, they used a checked-exception hierarchy. In Hibernate 3, that same hierarchy was changed to extend from RuntimeException instead. Spring is also mostly RuntimeException based. We are for most of the same reasons.
The idea is that RuntimeException hierarchies allow the end-user of the framework choice based on their needs - they can either catch the exception and handle it accordingly, or they can let it bubble up and let something else take care of it. The application developer would know best how and when to catch exceptions in a meaninful way, and RuntimeExceptions allow for more flexibility in that regard. However this approach requires more diligence from the framework development team - they must clearly document each Exception class/subclass as well as any method that could throw such exceptions. It requires great JavaDoc. But in my opinion, this is worth it - the documentation should be good anyway, and the end-user gets the flexibility they want. At least that's my take on it :) Regards, Les On Tue, Aug 26, 2008 at 10:53 PM, Joshua Partogi <[EMAIL PROTECTED]>wrote: > Hi Les, > > The problems is in using JPA entityManager inject to my spring bean > using @PersistenceContext. I configured the injection manually and it > works now. May I know the reason why are we using RuntimeException for > AuthenticationException? Just to add my knowledge bank of JSecurity. > :-D > > Cheers, > > On Wed, Aug 27, 2008 at 2:42 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > > Hi Joshua, > > > > As I understand it, this is strongly related to how your transaction > > boundaries are defined. Hibernate would close the HibernateSession when > a > > transaction is committed or rolled back (e.g. due to a RuntimeException). > > > > If a runtime exception is thrown (like the AuthenticationException), but > you > > catch it before the code that started the transaction exits, the > transaction > > won't be rolled back. > > > > Does that help? > > -- > Setting a new landmark. > Blog: http://joshuajava.wordpress.com/ > Twitter: http://twitter.com/thejavafreak >
