Sure, why not?

If your method does not accept null as an argument (as its documentation
will show), you might as well fail early.

Maybe your method tries to use the value, and will throw a NPE anyway,
but maybe it just stores the value for later and then the error will
be harder to track. And even if you use the value now, you might
change the method later, so it's safer to add the null check now.

/L

I guess the JVM will do this for you as soon as you use the value
(haven't tried enums yet.)

 Harald.

An enum instance is like an instance of a class. When used as a
parameter, its value could be null, like any other reference type
parameter.
How to handle it, entirely depends on what your method should do: if
null isn't allowed as value of the method's parameter, you could throw
an exception. In other cases a method might handle it "gracefully".

Hi!

"Effective Java," is a great book, and I did enjoy one Amazon
reviewer's comment on it; the comment seems applicable here (from
http://www.amazon.com/exec/obidos/tg/detail/-/0201310058/qid=1118654844/sr=8-1/r
ef=pd_csp_1/104-9588299-9954334?v=glance&s=books&n=507846):

The other caveat is that this book is written from the perspective of
writing public APIs. Bloch is the lead architect for the core JDK APIs
where the classes and APIs have special security considerations.
Several pieces of advice he gives apply absolutely to a public API
where you want to defend the API from malicious code. However, if the
code you are creating is intended for a less hostile and more trusting
environment, fully following all of his advice will result in
unnecessarily complex code. The one knock I give to the book is that
Bloch does not delineate the circumstances that would dictate
following his rather rigorous approach to bullet-proofing an API and
can leave the reader with the mistaken perception that the advice
applies equally to all categories of code.

.ed

www.EdmundKirwan.com - Home of The Fractal Class Composition.