On Thu, Jan 14, 2010 at 2:42 AM, Peter Ledbrook <[email protected]> wrote: >> NamingException is a checked exception. > > I would wrap it with a runtime exception then. It's been a while since > I played with LDAP, so do all cases of NamingException imply either a > system problem or programmer error?
I believe so. If the system is configured properly, there are no network/lookup problems, and the name corresponds to a valid ojbect, you should never get a NamingException. Currently our other out-of-the-box Realms wrap any checked exceptions (SQLException, etc) in an AuthenticationException or AuthorizationException and just let that propagate. I can change the LdapRealm to do this also, and I bet people wouldn't complain much with that solution, but it isn't as clean as a clear/meaningful exception indicating _why_ there is a problem. Developers would have to catch either exception, get the cause, then do instanceof checks to react accordingly if they wanted to. If they don't want to do that, they must subclass our out-of-the-box Realm (or write their own) and create custom exceptions. Is this OK? The big benefit of just keeping the current behavior (and wrapping in an AuthenticationException) is that we don't have to concern ourselves with creating a rich hierarchy that would try to suit most EIS environments, as Spring's DataAccessException hierarchy does. Instead we just let the Shiro end-user worry about this stuff by subclassing or via instanceof checks. What's better in this case? - Les
