You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Mingfai <mi...@gmail.com> on 2008/10/07 17:24:45 UTC

login() api throw AuthenticationException

hi,

I'm a newbie learning JSecurity. Your mission to be easy to understand and
simple to use are promising!

After reading the QuickStart guide, I have an immediate question. Why it use
exception to control the login flow? To my understanding, it's a
conventional practice in Java not to use exception to control logic flow.
reasons are, e.g. performance, distinguish between 'real' exception like the
backend db is failed.  Any comment?

Regards,
mingfai

Re: login() api throw AuthenticationException

Posted by Mingfai <mi...@gmail.com>.
well, thanks for your explanation.  i'm not too convinced, but I'm going to
continue may evaluation and will probably use it anyway via Grails JSecurity
Plugin. If you don't mind, I would like want to share some thoughts.

The point about non-OO for alternative, or whether it's truely exception,
are subjective and not arguable. So i don't argue about it. It would be
great if we could get other people's option. I wonder if somebody argue
about it in theserverside, what will people say. And I'll be equally happy
if I learn my idea about using exception is wrong, too. Basically, i read
from somewhere that there are ways to make exception handling fast enough in
modern JVM, but I don't remember the source.

Recently, I checked the JSR 303 Bean Validation API draft.  the validate()
method is quite similar to login() method. I'm *not* bring this as an
example to show sb else do not do in the JSecurity way, but I want to bring
the concept of message translation that I've learnt from that API, as when a
login() is rejected, we are very likely need to display an error message to
the user. And, IMHO, the validation API provides a convenient way to achieve
that.


   - The simplest validate API is:
   java.util.Set<InvalidConstraint>  validate(T object)

   - For InvalidConstraint, it holds the error type and message. e.g.
   Set violations = validator.validate( target );
   System.out.println( violations.iterator().next().getMessage() );
   //println a translated error mesage; i use this to illustrate how to get the
   message only. no one will really code like this.

   - The translation works by setting a MessageResolver (i.e. a translator)
   to the validator. The translator simply lookup a resource bundle for error
   message.


At the first site it looks odd, but later i find it has a lot of advantages.
First, it could achieve highest possible performance, IMHO. Second, it
provides a translated error message in a convenient way. I suppose for most
use cases, we need to turn an login exception to error message to show to
the user, and it does the job. Third, it supports multiple errors. (you
could throw only one type of exception. you certainly could workaround this.
but some people may want to know, e.g. the LDAP rejected the password and at
the same time the user profile database is down... . do you just throw the
password incorrect exception and ask the user to retry?!)

I read from the forum that you'll fix the API and won't change it easily
after releasing 1.0. Would you consider to review this particular API?

Regards,
mingfai

reference:
http://www.agimatec.de/documentation/public/agimatec-validation/site/apidocs/index.html





On Wed, Oct 8, 2008 at 7:30 AM, Les Hazlewood <lh...@apache.org> wrote:

> Hi Mingfai,
>
> They are only used in logic flow if something goes wrong.  That is,
> they are truly 'exceptions' - they shouldn't happen in most cases.  If
> they do happen, the exception hierarchy is rich enough for you to
> write code that adapts to the specific case of why the login failed.
>
> The only other way to achieve this logic flow without exceptions is to
> return a 'status code' of what went wrong, and then you use a switch
> statement on it.  This is horrible non-OO practice that is much uglier
> than catching exceptions and reacting the them accordingly.  With
> exceptions, your code will be more readable for the truly 'exceptional
> and aren't supposed to happen regularly' cases.
>
> Cheers,
>
> Les
>
> On Tue, Oct 7, 2008 at 11:24 AM, Mingfai <mi...@gmail.com> wrote:
> > hi,
> >
> > I'm a newbie learning JSecurity. Your mission to be easy to understand
> and
> > simple to use are promising!
> >
> > After reading the QuickStart guide, I have an immediate question. Why it
> use
> > exception to control the login flow? To my understanding, it's a
> > conventional practice in Java not to use exception to control logic flow.
> > reasons are, e.g. performance, distinguish between 'real' exception like
> the
> > backend db is failed.  Any comment?
> >
> > Regards,
> > mingfai
> >
>

Re: login() api throw AuthenticationException

Posted by Les Hazlewood <lh...@apache.org>.
Hi Mingfai,

They are only used in logic flow if something goes wrong.  That is,
they are truly 'exceptions' - they shouldn't happen in most cases.  If
they do happen, the exception hierarchy is rich enough for you to
write code that adapts to the specific case of why the login failed.

The only other way to achieve this logic flow without exceptions is to
return a 'status code' of what went wrong, and then you use a switch
statement on it.  This is horrible non-OO practice that is much uglier
than catching exceptions and reacting the them accordingly.  With
exceptions, your code will be more readable for the truly 'exceptional
and aren't supposed to happen regularly' cases.

Cheers,

Les

On Tue, Oct 7, 2008 at 11:24 AM, Mingfai <mi...@gmail.com> wrote:
> hi,
>
> I'm a newbie learning JSecurity. Your mission to be easy to understand and
> simple to use are promising!
>
> After reading the QuickStart guide, I have an immediate question. Why it use
> exception to control the login flow? To my understanding, it's a
> conventional practice in Java not to use exception to control logic flow.
> reasons are, e.g. performance, distinguish between 'real' exception like the
> backend db is failed.  Any comment?
>
> Regards,
> mingfai
>