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
