Re: why in permission ,can't do like this?
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