RE: field initializtion

["Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>]

> >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.

Joe, 

From other sources and NGs I've heard the opposite.  That returning null
from a user class is NOT acceptable and generally a pain in the arse.  i'm
looking to what others (not just Joe, people!) have seen is the norm.
Because Java is used on many platforms, there seem to be many different
opinions as to what is reasonable and what is not.  

I don't see where "bloat" would come from using

String newString = "";

as compared to

String newString = null;

The bloat comes from using

if (newString.equals("text"))

as compared to

if (newString != null) {
  if (newString.equals("text"))
    dothis;
}

That's just my opinion, though.  And you are most likely referring to bloat
at runtime as you describe later in your reply.

> 
> > 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.

That's what I was asking in the first email.  What is the difference between

String myString = new String();
and
String myString = "";
and
String myString = null;

Which ones produce the most unwanted "cycles", when is this acceptable (ie
classes, local variables in methods, etc.), and when is it not.  Just
looking for opinions, that's all.  When did M$ and testing come into the
equation?  

> 
> 
> > 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.  

Whoa!  Chill, Joe.  The smiley means a joke.  I am aware of try and catch.
But they don't seem any better than MONMSG MSGID(CPF0000) in most examples
I've seen.  

Rough week of teaching java to RPGers?  (this smiley intentionally left
blank).  

Brad
+---
| 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
+---