On Wed, 2006-03-29 at 11:47, Allen Gilliland wrote:
> vince kraemer wrote:
> > Byron Nevins wrote:
> >> Where is the "dangerous" part?
> >>
> >>
> >> String str = null; try {
> >> str =
> >> children.item(ii).getFirstChild().getNodeValue(); }
> >> catch (java.lang.NullPointerException npe) {
> >> str = ""; }
> >> jdbcResource.setDescription(str);
> >>
> >>
> > I hope you are being tongue in cheek here...
> >
> > using exceptions instead of testing for null is frowned on by many...
>
> I would agree that you should be testing for null on objects before
> using them if there is any expectation that the object may be null. A
> null pointer exception is a RuntimeException and AFAIK it is not
> considered a best practice to write code that expects a RuntimeException
> as the example above shows.
>
There are some places in the app server (CSIv2 server request
interceptor for RMI-IIOP requests to remote EJBs) where this
pattern occurs (due to an unfortunate public specification problem)
twice on every request (it's being fixed, but didn't quite make
it for HCF unfortunately). I think this impacts performance on
the order of 10% or so for the affected operations. This turns
out to be a pretty large affect for a rather small change.
Ken.