Re: Checking for null parameter
Jack wrote:
Have you some precise example to show how they helped you instead of "if
(canBeDone) { /* do it */ }" , please ?
Yes, in fact I was just going over an entity I had written a while back with
'assert'.
First, a quote from
<http://java.sun.com/javase/6/docs/technotes/guides/language/assert.html>
Experience has shown that writing assertions while programming is one of the
quickest and most effective ways to detect and correct bugs. As an added
benefit, assertions serve to document the inner workings of your program,
enhancing maintainability.
also
There are many situations where it is good to use assertions, including:
* Internal Invariants
* Control-Flow Invariants
* Preconditions, Postconditions, and Class Invariants
There are also situations where you should not use them:
followed by a list of situations that should not use 'assert', and why not.
Use 'assert' for things under your control. Public variable values aren't, so
you don't use 'assert' to check them. Also, 'assert' is supposed to be
disabled in production.
Consider an entity class Employee, with a mandatory 'name' attribute. One way
to enforce that is to demand a non-null name in the constructor.
public class Employee
{
private static final String NULLNAME = "null name";
private String name;
/** Constructor with mandatory name.
* @param name <code>String</code> mandatory attribute.
* @throws IllegalArgumentException if <code>name == null</code>.
*/
public Employee( String name )
{
setName( name );
}
/** Mutator for <code>name</code> attribute.
* @param name <code>String</code> mandatory attribute.
* @throws IllegalArgumentException if <code>name == null</code>.
*/
public void setName( String name )
{
if ( name == null )
{
throw new IllegalArgumentException( new NullPointerException(
NULLNAME ));
}
this.name = name;
assert name != null;
}
/* Accessor for <code>name</code> attribute.
* @return String name attribute.
*/
public final String getName()
{
assert name != null;
return name;
}
}
There is no point to using 'if' instead of 'assert', because the code
*guarantees* that the invariant holds. Using an 'if' would be unnecessary
overhead.
However, should an overriding class ever fail to set 'name', the responsible
developer of that subclass will have turned on 'assert' to be certain they
didn't violate any of the superclass's invariants. Whoops! They didn't set
name. Now they fix their code, maybe repeat the invariant as a postcondition
of the constructor, which you will note that I completely forgot to do in my
example above. Bad me.
public Manager extends Employee
{
/** Constructor with mandatory name.
* @param name <code>String</code> mandatory attribute.
*/
public Manager String name )
{
super( name );
}
/** Mutator for <code>name</code> attribute.
* @param name <code>String</code> mandatory attribute.
* @throws IllegalArgumentException if <code>name == null</code>.
*/
public void setName( String name )
{
this.name = name;
registerWithManagementRoster( name );
}
}
I wrote a couple of bugs into these implementations to show how the 'assert'
in the get method would help.
--
Lew