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.
Just my .02 cents though.
-- Allen
>
> In the "one shot case" it isn't a real performance killer, but if this
> pattern works its way into an inner loop... molasses time.
>
> There are a couple ways this could work its way into a loop...
>
> 1. somebody starts calling a method that worms its way to this point...
> in some loop that they have written.
>
> 2. The person that uses this coding pattern keeps using it and it
> becomes habit...
>
> 3. somebody needs to "do something like this" and copy/pastes this code
> (or probably some larger block that contains this flow-of-control
> pattern) into their code...
>
> vbk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>