why in permission ,can't do like this?

Discussion in 'Java' started by junzhang1983@gmail.com, Feb 18, 2008.

  1. Guest

    public final class MyPermission extends java.security.BasicPermission
    {
    public MyPermission( String name )
    {
    super(name);
    if ((name == null) ||( !(name.equals("getInstance") ))|| (!
    (name.equals("setUtil"))))
    throw new IllegalArgumentException();

    }
    }

    in program, use like below:
    SecurityManager sm = System.getSecurityManager(); //sm is not null
    if (sm != null)
    sm.checkPermission( new MyPermission("setUtil") );

    when program is running, it will throw Error like below:
    java.lang.ExceptionInInitializerError:
    java.lang.illegalArgumentException

    l don't know why throw above Error,l think add belw code:
    if ((name == null) ||( !(name.equals("getInstance") ))|| (!
    (name.equals("setUtil"))))
    throw new IllegalArgumentException();
    will not influence the program,
    who can explain why?
    thank you.
    , Feb 18, 2008
    #1
    1. Advertising

  2. Peter Duniho Guest

    On Sun, 17 Feb 2008 17:49:59 -0800, <> wrote:

    > [...]
    > l don't know why throw above Error,l think add belw code:
    > if ((name == null) ||( !(name.equals("getInstance") ))|| (!
    > (name.equals("setUtil"))))
    > throw new IllegalArgumentException();
    > will not influence the program,
    > who can explain why?


    Your condition will _always_ evaluate to true. It's true if the string is
    _either_ not equal to "getInstance" or not equal to "setUtil". The string
    can never be equal to both at the same time, so it will always be not
    equal to at least one of those strings.

    You've got an awful lot of parantheses in there, which makes it a lot
    harder to read, by the way.

    I suspect you'd rather have an if() statement that looks like this:

    if (name == null || !(name.equals("getInstance") ||
    name.equals("setUtil")))

    In other words, the condition is true if "name" is null, or not equal to
    either string.

    Though, all that said, maybe it's just because I'm unfamiliar with the
    BasicPermission class and techniques generally used with it, but it just
    feels wrong to me that you allow the client code to pass a string, but
    then insist that it must be one of two strings. Maybe there's a better
    way to structure that part of the code.

    Pete
    Peter Duniho, Feb 18, 2008
    #2
    1. Advertising

  3. Lew Guest

    Peter Duniho wrote:
    > Though, all that said, maybe it's just because I'm unfamiliar with the
    > BasicPermission class and techniques generally used with it, but it just
    > feels wrong to me that you allow the client code to pass a string, but
    > then insist that it must be one of two strings. Maybe there's a better
    > way to structure that part of the code.


    One more verbose way to handle the illegal argument check is with a specific
    separate null value check. Though it's verbose, it is nicely
    self-documenting. Whether you want to treat null as an out-of-band illegal
    value like this depends on the semantics of your application model. It's
    perfectly legitimate otherwise to treat null as just another illegal value.

    if ( name == null )
    {
    throw new IllegalArgumentException(
    new NullPointerException( "null name" ));
    }
    if ( name.equals( "getInstance" ))
    {
    doNameInstanceThing();
    }
    else if ( name.equals( "setUtil" ))
    {
    doSetUtilThing();
    }
    else
    {
    throw new IllegalArgumentException( "bad name: "+ name );
    }

    Then I look at that and want doWhatever() methods to be the implementors of a
    PermissionHandler interface, selected from a Map based on the passed 'name'
    String. Getting null for a Handler from the Map means an illegal argument.

    Class <? extends PermissionHandler> clazz = handlers.get( name );
    if ( clazz == null )
    {
    throw new IllegalArgumentException( "bad name: "+ name );
    }
    PermissionHandler handler = clazz.newInstance();
    handler.doWhatever( name );

    (error checks omitted)

    Then the String 'name' argument can come from, say, a deployment descriptor or
    properties file, as can the 'handlers' elements. It makes perfect sense for
    code to accept client-driven parameters if it's a framework setup like that.
    The clients in this case are disciplined classes working off well-documented
    setup files, so they are relatively trustworthy. Of course, the accepting
    class must produce meaningful log messages for the operations folks in case
    there is a mistake.

    --
    Lew
    Lew, Feb 18, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    877
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,806
    Smokey Grindel
    Dec 2, 2006
  3. Patrick Kowalzick
    Replies:
    5
    Views:
    469
    Patrick Kowalzick
    Mar 14, 2006
  4. active
    Replies:
    4
    Views:
    275
    active
    Apr 3, 2007
  5. Adam Short
    Replies:
    2
    Views:
    428
    Bob Barrows [MVP]
    Apr 14, 2005
Loading...

Share This Page