RE: field initializtion

---------- Original Message ----------------------------------
From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
Reply-To: JAVA400-L@midrange.com
Date: Mon, 26 Mar 2001 12:49:44 -0600

>I guess my main question is so I don't have to check for null.  
<...snip...>
>will fail if field is null with a null pointer exception error.  So, to
>check for null or "" (basically a blank value) a little extra work is
>involved.

You'd rather bloat your code with unnecessary assignments than type, what?  A 
couple of seconds of keying max?  A couple of seconds which would probably make 
your code more readable, because you should only be checking for a null value 
when that's a REASONABLE return from the method.  You should NOT be checking 
for null as a byproduct of a programming mistake, but only as a legitimate test 
because the method returns null under certain conditions.

> I know it's safer to check for not equals, but sometimes it's nicer
> to not do that.  Inevitably there will be a point where I will forget
> to check for null and my program will bomb at runtime with a null
> pointer exception. That's really what I want to avoid.

So you'd rather waste your end user's cycles assigning zero-length string 
literals in order to be able to handle the situation where you screw up as a 
programmer and have a null pointer.  A situation which should be caught by you 
during unit testing, not by your end user, unless you're a believer in the 
Microsoft "send it out and see what breaks" school of hacking.  Not what I call 
a particularly good use of the language.


> But there's no *PSSR in Java.  ;)

Man, I'm getting sick of those cute little smileys.  There's something better 
than a *PSSR, Brad, it's called an exception.  You can "try" and "catch" for 
any exception that might occur.  I doubt that you'll want to use it, though, 
because it requires (horrors!) actual coding.  Since it's rare that you can 
actually recover from a *PSSR, about all they're good for is to abend quietly 
after progamming mistakes without throwing up a hard halt that might draw 
attention to the poor code that caused the error.  Exceptions are for people 
who actually think about their programming and figure out how to handle errors 
ahead of time.

Joe
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---