Agreed, Realm implementers should handle these cases. On Wed, Jan 6, 2010 at 5:31 PM, Jeremy Haile <[email protected]> wrote:
> It does if you create a subclass of AuthenticationException called > SystemErrorAuthenticationException ;-) (or whatever) > > > Les Hazlewood wrote: > >> I think of those two exceptions and their hierarchies as representing >> user-attributed "expected but not frequent" exceptions related to an >> end-user's failure to authenticate or authorize properly - locked >> account, incorrect password, etc. These kind of exceptions are a >> totally different class of exceptions compared to data source failure. >> >> Then there is the issue that, if say a NamingException occurs in >> either during authentication or authorization, it appears that we'd >> have to create two separate Exceptions under each hierarchy >> representing the same system-level problem. Not too ideal I don't >> think. >> >> I don't think it is nice for example to just catch the problem and >> throw as a generic AuthenticationException - this doesn't allow the >> developer catching these exceptions to differentiate between >> user-level problems and system-level problems. >> >> Thoughts? >> >> - Les >> >> On Wed, Jan 6, 2010 at 4:45 PM, Jeremy Haile<[email protected]> wrote: >> >> >>> Don't we already offer two hierarchies for this purpose? >>> AuthenticationException and AuthorizationException >>> >>> >>> Les Hazlewood wrote: >>> >>> >>>> This issue: >>>> >>>> https://issues.apache.org/jira/browse/SHIRO-120 >>>> >>>> raises a good point. We shouldn't be swallowing exceptions from >>>> Realms anywhere. We should instead offer a nice Exception hierarchy >>>> to allow end-users to react to problems. >>>> >>>> The best exception hierarchy I've seen exemplifying this is Spring's >>>> DataAccessException and subclasses. >>>> >>>> Should we incorporate something similar? If so, any recommendations? >>>> >>>> - Les >>>> >>>> >>>> >>>
