NullPointerException

[Jack]

Does java NullPointerException always cause crash?

Thanks.

 

[Roedy Green]

Does java NullPointerException always cause crash?

it never causes a crash. Only a big in the JVM causes a crash. If
you don't catch is the run time will, and print out a stack trace.

If you wanted to do something else you would do:

try {
....
}
catch ( NullPointerExeception e )
{
err.println( "Not again!");
e.printStackTrace( err );
}
--
Roedy Green Canadian Mind Products
http://mindprod.com

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)

 

[Eric Sosman]

Does java NullPointerException always cause crash?

No. Yes. Mu.

Define "crash."

 

[Lew]

Jack wrote, quoted or indirectly quoted someone who said :

Does java [sic] NullPointerException always cause crash?

According to Roedy Green :

Theoretically you are right. However I did encounter JVM implementations
which occasionally had trouble with NullPointerException (including a
port of Sun's JVM for FreeBSD).

Come on, guys, Jcheeze! The OP clearly meant crash of his program, not the JVM.

The answer is that uncaught exceptions will cause termination of a program.
Ones you catch and deal with properly will not.

'NullPointerException', or "NPE" as some abbreviate it, is a runtime
exception, that is, it is a subtype of 'RuntimeException'. Runtime exceptions
generally represent a programmer mistake. A properly-written program will not
throw an NPE.

Runtime exceptions are designed not to be caught, but to cause a program to
abort. It is not usual (nor, in my opinion, usually correct) to handle
runtime exceptions routinely. All such should be prevented, not handled. If
you want to insist that an exception be caught and handled, use a checked
exception, one that is a subtype of 'Exception' but not 'RuntimeException'.
Read the tutorials on java.sun.com and other introductory material on
exceptions for more information.

 

[Lew]

Uh. You, of all people, complaining about pedantry, however irrelevant
to the question at hand?

How droll.

I just can't make anyone happy, can I? I put forth the helpful attitude
people have always told me here they want from me and you dump a load of
manure on me.

How droll.

And I certainly didn't complain about pedantry. I complained pedantically
that people were misinterpreting the OP's obvious intent.

If helping the querent was wrong, I don't want to be right.

 

[Mike Schilling]

Runtime exceptions are designed not to be caught, but to cause a
program to abort. It is not usual (nor, in my opinion, usually
correct) to handle runtime exceptions routinely.

The obvious exception here arises when calling less trusted code. If a web
application throws a runtime exception while processing a request, the
container should catch it and handle it by returning an error reponse to the
caller, not abort. Likewise, when a test harness calls code it's testing,
runtime exceptions should be caught and reported and the next independent
test case run.

 

[Roedy Green]

To be precise, in many JVM, null references are not checked before
access; instead, the access is trapped by the OS, which generates a
system-level exception (on Unix-like systems, a SIGSEGV or SIGBUS
signal). The JVM intercepts that signal, obtains the faulty code
address, and converts the signal into a NullPointerException which is
then thrown in the offending thread.

How did you discover this?
--
Roedy Green Canadian Mind Products
http://mindprod.com

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)

 

[Roedy Green]

Come on, guys, Jcheeze! The OP clearly meant crash of his program, not the JVM.

I would say most programmers reserve the word "crash" for the JVM
blowing up, not just an unhandled exception. Dying with an unhandled
exception is relatively orderly behaviour compared with unpredictable
crash behaviour like the old C days when you wrote off the end of an
array, and clobbered code that was later executed.

The word "hang" implies the program freezes and is unresponsive to
mouse or keyboard input.

What would you call an "unhandled exception"? Maybe just a "failure"?

"Didn't work" is a sloppy term that could even be used for a program
that ran to completion, but gave a result different from expected.

There is the very orderly System.exit( 1 );

If you are into it, let's tighten up the vocabulary, create history,
and I will document the new precise meanings, then Lew can have fun
razzing the newbies when they use the terms improperly.

I fiercely guard the term "leak" and insist on "packratting" or
"loitering" because I want people to understand that Java can't have
leaks in the C++ sense, so long as the JVM is bug free.
--
Roedy Green Canadian Mind Products
http://mindprod.com

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)

 

[Lew]

Have you in fact helped the querent? After all, you stated that a
NullPointerException always terminates the program. Even ignoring that

Nope, I said uncaught exceptions terminate the program. Very different.

you've arbitrarily chosen a different definition of "crash" than Roedy
chose, however more likely that definition might be to be correct it
still remains that your conclusion wasn't precisely correct.

In what way? Name one example where an uncaught exception does not crash the
program.

That is, I will (pedantically) point out that you claimed that
"[exceptions] that YOU catch and deal with properly will not [cause
termination of a program]". Clearly implying that exceptions YOU do NOT
catch and deal with property WILL cause termination of the program.

You added that implication. I never stated it. Also, it is clear that if YOU
use a library that catches an exception, then YOU are responsible that it got
caught, so, pedantically speaking, YOU are still the one catching it by dint
of relying on the library's behavior. So even if the implication you claim is
so clear, it's still correct.

Except that there are examples of areas of the Java API where exceptions
are caught on your behalf, not by YOU.

To be pedantic, I said, "The answer is that uncaught exceptions will cause
termination of a program. Ones you catch and deal with properly will not. "

I did not say, "Exceptions that YOU catch", as you misquoted. I completely
did not talk about the corner case where someone else catches the exception.

(Emphasis added above for clarity)

It's not adding clarity if you change the meaning of what I said by adding
words that weren't even there, then emphasizing them.

Okay, you may now feel free to complain about my pedantry.

Complain about it? I thrive on it!

 

[Lew]

If you are into it, let's tighten up the vocabulary, create history,
and I will document the new precise meanings, then Lew can have fun
razzing the newbies when they use the terms improperly.

There you go again. It was not the newbie whom I razzed. It was your
interpretation and refusal to answer the newbie's question that I razzed. It
was the newbie I supported. Such revisionism, Roedy!

 

[Roedy Green]

it never causes a crash. Only a big in the JVM causes a crash. If
you don't catch is the run time will, and print out a stack trace.

I sound like Peter Sellers with his "mith" in the closet. That should
be "Only a BUG in the JVM causes a crash."
--
Roedy Green Canadian Mind Products
http://mindprod.com

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)

 

[Lew]

That is, I will (pedantically) point out that you claimed that
"[exceptions] that YOU catch and deal with properly will not [cause
termination of a program]". Clearly implying that exceptions YOU do
NOT catch and deal with property WILL cause termination of the program.

I did not say, "Exceptions that YOU catch", as you misquoted. I

To be pedantic, I said that wrong. I meant to cite:
"I did not say, 'exceptions YOU do NOT catch', ..."

 

[Arne Vajhøj]

I would say most programmers reserve the word "crash" for the JVM
blowing up, not just an unhandled exception.

I am not so sure about that.

You write a C/C++ program that does something that makes
the machine throw an exception, so the program
crashes if it is not handled.

You write a Java program that does something
that makes the JVM throw an exception, so the
program crashes if it is not handled.

Same thing.

So if you are writing Java apps, then an unhandled
exception in Java is a crash.

But if you are writing JVM's, then you need the C/C++
code in the JVM to crash before you consider it a crash.

The number of people writing Java apps is a lot greater
than the number of people writing JVM's.

Arne

 

[Arved Sandstrom]

I am not so sure about that.

You write a C/C++ program that does something that makes
the machine throw an exception, so the program
crashes if it is not handled.

You write a Java program that does something
that makes the JVM throw an exception, so the
program crashes if it is not handled.

Same thing.

So if you are writing Java apps, then an unhandled
exception in Java is a crash.

But if you are writing JVM's, then you need the C/C++
code in the JVM to crash before you consider it a crash.

The number of people writing Java apps is a lot greater
than the number of people writing JVM's.

Arne

Most business users I know rightfully understand a simple truth - the
application is either working or it's not. They don't actually use the
word "crash" often - the popular term is "outage", which is descriptive
enough. And they could really not care less whether it was the JVM that
locked up or crashed, or it was their J2EE application that crashed, or
it was their J2EE application that's in deadlock or just glacially slow.
It's all an outage.

If someone wants to use the word "crash" to describe the end of useful
execution of their application due to an error, as opposed to the JVM
itself blowing up, I'm not going to say they're wrong. And the business
user will call both an "outage".

AHS

 

[Mike Schilling]

Most business users I know rightfully understand a simple truth - the
application is either working or it's not. They don't actually use the
word "crash" often - the popular term is "outage", which is
descriptive enough. And they could really not care less whether it
was the JVM that locked up or crashed, or it was their J2EE
application that crashed, or it was their J2EE application that's in
deadlock or just glacially slow. It's all an outage.

Likewise, if a service is unavailble for networking reasons completely
unrelated to the running of the service itself, that's still an outage.