Hi all!
Two points:
[1] You shouldn't explicitely test for "null" pointers, unless a null
pointer would normally be expected.
If we can assume that "sm" shouldn't be null in a bug free
program/library, then
try { sm.XXX(); } catch (NullPointerException e){}
is the right thing to do, as in a normal run of the program "0
processor" cylcle will be devoted to testing the null property. This
can be an important gain in innerloops.
[2] But it seems that in this specific example, a null pointer is
expected; if it wasn't, the code should have been:
sm.XXX();
without any try/catch block.
The general rule for exception is: An exception denotes an
"exceptional" situation (no surprize!), and thus should not be used on
the normal execution path of a program/library.
It is usually a bad practice to catch runtime exceptions, unless you do
so for a good reason. Bad program design is not a good reason.
A runtime system will very rarely try to optimize is the handling of
exceptions. For example, a SIGFAULT can be quite slow to handle by the
underlying OS. If the interpreter/JIT depends on system signals to
catch these, then you can't expect this to be fast. You certainly don't
want any of this to be on the normal execution path of your programs.
In other words: If you expect "sm" to be null when the
program/libraries are bug free (and not exceptional situation has
happened), then you should not rely on the exception mechanism to test
for this condition.
Etienne
--
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc. e-mail: [EMAIL PROTECTED]
Author of SableVM: http://www.sablevm.org/
----------------------------------------------------------------------
