NullPointerException

Discussion in 'Java' started by Jack, Feb 25, 2010.

  1. Jack

    Jack Guest

    Does java NullPointerException always cause crash?

    Thanks.
    Jack, Feb 25, 2010
    #1
    1. Advertising

  2. Jack

    Roedy Green Guest

    On Thu, 25 Feb 2010 00:09:22 -0800 (PST), Jack <>
    wrote, quoted or indirectly quoted someone who said :

    >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)
    Roedy Green, Feb 25, 2010
    #2
    1. Advertising

  3. Jack

    Eric Sosman Guest

    On 2/25/2010 3:09 AM, Jack wrote:
    > Does java NullPointerException always cause crash?


    No. Yes. Mu.

    Define "crash."

    --
    Eric Sosman
    lid
    Eric Sosman, Feb 25, 2010
    #3
  4. Jack

    Lew Guest

    Jack wrote, quoted or indirectly quoted someone who said :
    >>> Does java [sic] NullPointerException always cause crash?


    According to Roedy Green :
    >> it never causes a crash.


    Thomas Pornin wrote:
    > 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
    Lew, Feb 25, 2010
    #4
  5. Jack

    Lew Guest

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


    Peter Duniho wrote:
    > 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.

    --
    Lew
    Lew, Feb 25, 2010
    #5
  6. Lew wrote:
    > 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.
    Mike Schilling, Feb 25, 2010
    #6
  7. Jack

    Roedy Green Guest

    On 25 Feb 2010 13:26:18 GMT, Thomas Pornin <> wrote,
    quoted or indirectly quoted someone who said :

    >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, Feb 25, 2010
    #7
  8. Jack

    Roedy Green Guest

    On Thu, 25 Feb 2010 10:50:42 -0500, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >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)
    Roedy Green, Feb 25, 2010
    #8
  9. Jack

    Lew Guest

    Peter Duniho wrote:
    > 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
    Lew, Feb 25, 2010
    #9
  10. Jack

    Lew Guest

    Roedy Green wrote:
    > 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!

    --
    Lew
    Lew, Feb 25, 2010
    #10
  11. Jack

    Roedy Green Guest

    On Thu, 25 Feb 2010 00:26:59 -0800, Roedy Green
    <> wrote, quoted or indirectly quoted
    someone who said :

    >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)
    Roedy Green, Feb 25, 2010
    #11
  12. Jack

    Lew Guest

    Peter Duniho wrote:
    >> 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.


    Lew wrote:
    > 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', ..."

    --
    Lew
    Lew, Feb 25, 2010
    #12
  13. Jack

    Arne Vajhøj Guest

    On 25-02-2010 16:11, Roedy Green wrote:
    > On Thu, 25 Feb 2010 10:50:42 -0500, Lew<> wrote,
    > quoted or indirectly quoted someone who said :
    >> 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.


    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
    Arne Vajhøj, Feb 26, 2010
    #13
  14. Arne Vajhøj wrote:
    > On 25-02-2010 16:11, Roedy Green wrote:
    >> On Thu, 25 Feb 2010 10:50:42 -0500, Lew<> wrote,
    >> quoted or indirectly quoted someone who said :
    >>> 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.

    >
    > 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
    Arved Sandstrom, Feb 26, 2010
    #14
  15. Arved Sandstrom wrote:
    > 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.
    Mike Schilling, Feb 26, 2010
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jon A. Cruz

    Re: NullPointerException Error??

    Jon A. Cruz, Jul 6, 2003, in forum: Java
    Replies:
    0
    Views:
    508
    Jon A. Cruz
    Jul 6, 2003
  2. Tohru Kao
    Replies:
    3
    Views:
    417
    Neil Masson
    Jul 14, 2003
  3. Tohru Kao
    Replies:
    1
    Views:
    380
    Chris
    Jul 8, 2003
  4. Dhek Bhun Kho
    Replies:
    0
    Views:
    2,225
    Dhek Bhun Kho
    Jul 9, 2003
  5. Tom
    Replies:
    12
    Views:
    8,022
    Chris Smith
    Aug 5, 2003
Loading...

Share This Page