RE: field initializtion

["Joe Teff" <JoeTeff@xxxxxxxxxxxxx>]

I will answer this here as many probably aren't subscribed to java101 yet.
Follow up can be on that list.

I will attempt to follow both lists and help with answering
beginner/intermediate questions, though I can't promise to be timely. My
responses will be mostly in the evening and weekends (and sometimes a day or
two behind). This can't be helped.

Instance variables are automatically initialized to thier zero value when
the object is created. This means numbers are 0, boolean is false and
reference variables are null.

Local variables are not initialized when the method is started. That is why
you are forced to initialize them before using them. This is a performance
thing. If you didn't initialize them, you could see what was in that memory
prior to your using it. This would violate security. Imagine if you could
allocate a huge String and then examine it.

I do not see anything wrong with returning a null. It has to be handled a
little differently than other values is all. Using null in Java is an
everyday thing.

There is a difference between the following statements:

   String a = "Hello";
   String b = new String("Hello");

Strings are immutable, which means once given a value, it can never change.
Any changes to a String actually causes a new object to be instantiated and
that new address returned to you. Why they are immutable is better left for
another discussion. When ever you use a String literal, Java will check a
string pool to see if that value exists and return that memory pointer to
you. It's ok for two variables to point to the same memory because strings
are immutable. The new keyword, however, always creates a new object.

The statement "if (a == b)" would equate to false. When using "==" on
reference variables, it actually checks the contents of the variable which
is the memory address. As they would be different objects, the memory
addresses would not be equal.

The statement "a = b;" would cause b to contain the same memory address as
a, not copy the contents of the object that b is pointing to the object that
a points to.

Not sure if that answered your questions or not.

Oh - the *PSSR one.

Essentially doing a try-catch block surrounding your entire method and
catching Throwable would in essence do the same thing that *PSSR does. For
example:

   public void print() {
      try {
         // all of your code here
      }
      catch (Throwable exc) {
         // some error processing here
      }
   }

This would catch everything including Exceptions, RuntimeExceptions and
Errors. This really is considered bad form and being lazy though.

Joe Teff

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