To check or not to check for NULL?

[Mike]

That is the question!

Should I always check for the null value after using the new operator
to create a new object (of any type)?

JButton button = new JButton("test");

if (button== null)
System.out.println("Errror Message");

Or am I just wasting time?

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike schreef:

That is the question!

Should I always check for the null value after using the new operator
to create a new object (of any type)?

JButton button = new JButton("test");

if (button== null)
System.out.println("Errror Message");

Or am I just wasting time?

You are. If the object could not created, an exception will be thrown.
Useful thing, exceptions, it eliminates the need to check for return
values.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkjXuHgACgkQBGFP0CTku6P/CACdH9ZAmTjyU/izf2sCZIzx2iu2
o8wAnRH6humlTfPQNP3gouU7x47s3o+Q
=yRP0
-----END PGP SIGNATURE-----

 

[Joshua Cranmer]

That is the question!

Should I always check for the null value after using the new operator
to create a new object (of any type)?

JButton button = new JButton("test");

if (button== null)
System.out.println("Errror Message");

Or am I just wasting time?

A new either returns a new object or throws an exception or error. Most
specifically, if there is no memory left, it will throw an
OutOfMemoryError. There is no need, therefore, to check for null.

 

[Joshua Cranmer]

The obvious answer seems to be

try

{
JButton button = new JButton("test");
}
catch (Exception e)
{
System.out.println("Error Message");
}

If you want to get the out of memory case too, you'll have to catch
OutOfMemoryError too. But I don't recommend trying to catch that since
too many things can go wrong.

Also, you will generally only need to catch the checked exceptions, at
which point the compiler will complain if you don't catch.

 

[Lew]

If you want to get the out of memory case too, you'll have to catch
OutOfMemoryError too. But I don't recommend trying to catch that since
too many things can go wrong.

Also, you will generally only need to catch the checked exceptions, at
which point the compiler will complain if you don't catch.

And do more than write to System.out with the error messsage. Logging
is best, System.err is better than System.out, and the complete and
utter failure to recover from or rethrow the exception will not help
the program.

 

[Roedy Green]

Should I always check for the null value after using the new operator
to create a new object (of any type)?

No point. If the new fails you get an exception not a null.

 

[Tom Anderson]

That is the question!

Should I always check for the null value after using the new operator
to create a new object (of any type)?

JButton button = new JButton("test");

if (button== null)
System.out.println("Errror Message");

Or am I just wasting time?

A 'new' expression will never, *ever* evaluate to null, so this is
*always* a waste of time. This is not C - if there isn't enough memory,
you get an OutOfMemoryError, not a null value.

tom

 

[Mike]

Then, the question is- should one even catch "OutOfMemoryError" at all
every time an object is created? What should be the right course of
action? System.exit(1)?

 

[Mike]

Joshua,

If you want to get the out of memory case too, you'll have to catch
OutOfMemoryError too. But I don't recommend trying to catch that since
too many things can go wrong.

So don't catch it (the Error- OutOfMemoryError ) all? And why would I
need to catch the exception as the other person suggested? I thought
new operator throws an Error, not an Exception. I'm not sure why Hakan
suggested catching an Exception.

 

[Joshua Cranmer]

Then, the question is- should one even catch "OutOfMemoryError" at all
every time an object is created? What should be the right course of
action? System.exit(1)?

There's a reason that the OutOfMemoryError is an error--you shouldn't
catch it, unless you have a very good reason.

1. Almost anything can generate an OOM error. For example, calling a
function that only puts locals on the stack might do it in extremely
tight situations.
2. The error might not be thrown in a convenient location.
3. What would you do if you caught it? Try to free memory? If that's
what you're thinking, try using Java's SoftReference which interfaces
with the garbage collector itself. If you merely want to die, then the
VM will do it for you if you don't catch. If you want to display an
error message or do other handling, far better to unify it all at a
top-level area (e.g., uncaught exception handlers) since your entire
setup is most likely in pieces anyways.

There's no real point to catching what should be a rare condition when
recovery is impractical and the potential source is nearly every line of
code.

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Cranmer schreef:

There's a reason that the OutOfMemoryError is an error--you shouldn't
catch it, unless you have a very good reason.

1. Almost anything can generate an OOM error. For example, calling a
function that only puts locals on the stack might do it in extremely
tight situations.
2. The error might not be thrown in a convenient location.
3. What would you do if you caught it? Try to free memory? If that's
what you're thinking, try using Java's SoftReference which interfaces
with the garbage collector itself. If you merely want to die, then the
VM will do it for you if you don't catch. If you want to display an
error message or do other handling, far better to unify it all at a
top-level area (e.g., uncaught exception handlers) since your entire
setup is most likely in pieces anyways.

There's no real point to catching what should be a rare condition when
recovery is impractical and the potential source is nearly every line of
code.

There are some cases where it makes sense to catch an OOME, for example
in testing code in which you want to try out how big an input some code
can handle, where you have a loop repeating with ever bigger inputs and
if it throws an OOME, you break out of the loop and report the test
results, or start the next test etc. In production code, however, I
indeed see little use for it. You could think of an optional
memory-intensive computation which you try and if it doesn’t succeed,
you use some kind of back-up system.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkjcx4oACgkQBGFP0CTku6MiCwCgzLnwcClNIRp44nlS78AZQVtX
8EIAnj3mFEurhSZqgZvYiFwnyaZVA1FF
=YE07
-----END PGP SIGNATURE-----

 

[Joshua Cranmer]

There are some cases where it makes sense to catch an OOME, for example
in testing code in which you want to try out how big an input some code
can handle, where you have a loop repeating with ever bigger inputs and
if it throws an OOME, you break out of the loop and report the test
results, or start the next test etc. In production code, however, I
indeed see little use for it. You could think of an optional
memory-intensive computation which you try and if it doesn’t succeed,
you use some kind of back-up system.

The problem with trying to catch OOME is that it can be thrown
*anywhere.* Your computation may be the memory hog, but the error might
be thrown when the GUI updates itself and therefore completely the wrong
thread.

 

[Daniel Pitts]

The problem with trying to catch OOME is that it can be thrown
*anywhere.* Your computation may be the memory hog, but the error might
be thrown when the GUI updates itself and therefore completely the wrong
thread.

Although, if it is your alloc that fails specifically, that gives you
some ability to handle it. The goal is to handle the case where you
allocate "way too much", rather than "almost too much". ImageIO code
does this I believe.