Checked and unchecked exceptions. A clearer explanation please.

Discussion in 'Java' started by exquisitus, May 5, 2005.

  1. exquisitus

    exquisitus Guest

    I've just been browsing through the Java tutorial which describes a
    Nonruntime excption as:

    "Nonruntime exceptions are exceptions that occur in code outside of the
    Java runtime system. For example, exceptions that occur during I/O are
    nonruntime exceptions. The compiler ensures that nonruntime exceptions
    are caught or specified; thus, they are also called checked exceptions."

    Later
    (http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html)
    the tutorial then lists the ff code:

    public Object pop() throws EmptyStackException {
    Object obj;

    if (size == 0) {
    throw new EmptyStackException();
    }

    obj = objectAt(SIZE - 1);
    setObjectAt(SIZE - 1, null);
    size--;
    return obj;
    }

    And states: "Note that the declaration of the pop method contains a
    throws clause. EmptyStackException is a checked exception"


    My question is that why is EmptyStackException a checked exception (when
    NullPointerException for example - is unchecked?). Surely, the
    designation annot be arbitary?

    Could someone please provide a simpler/less ambiguous explanation of the
    logic behind Checked and Unchecked exceptions?

    Many Thanks
     
    exquisitus, May 5, 2005
    #1
    1. Advertising

  2. exquisitus

    Adam Maass Guest

    "exquisitus" <> wrote:
    > I've just been browsing through the Java tutorial which describes a
    > Nonruntime excption as:
    >
    > "Nonruntime exceptions are exceptions that occur in code outside of the
    > Java runtime system. For example, exceptions that occur during I/O are
    > nonruntime exceptions. The compiler ensures that nonruntime exceptions are
    > caught or specified; thus, they are also called checked exceptions."
    >
    > Later
    > (http://java.sun.com/docs/books/tutorial/essential/exceptions/throwing.html)
    > the tutorial then lists the ff code:
    >
    > public Object pop() throws EmptyStackException {
    > Object obj;
    >
    > if (size == 0) {
    > throw new EmptyStackException();
    > }
    >
    > obj = objectAt(SIZE - 1);
    > setObjectAt(SIZE - 1, null);
    > size--;
    > return obj;
    > }
    >
    > And states: "Note that the declaration of the pop method contains a throws
    > clause. EmptyStackException is a checked exception"
    >
    >
    > My question is that why is EmptyStackException a checked exception (when
    > NullPointerException for example - is unchecked?). Surely, the designation
    > annot be arbitary?
    >
    > Could someone please provide a simpler/less ambiguous explanation of the
    > logic behind Checked and Unchecked exceptions?
    >


    RuntimeException and its subclasses are unchecked exceptions. Error and its
    subclasses are unchecked exceptions. All other exceptions are checked
    excetpions.

    -- Adam Maass
     
    Adam Maass, May 6, 2005
    #2
    1. Advertising

  3. exquisitus

    HK Guest

    exquisitus wrote:
    >
    > And states: "Note that the declaration of the pop method contains a
    > throws clause. EmptyStackException is a checked exception"
    >
    >
    > My question is that why is EmptyStackException a checked exception

    (when
    > NullPointerException for example - is unchecked?). Surely, the
    > designation annot be arbitary?
    >
    > Could someone please provide a simpler/less ambiguous explanation of

    the
    > logic behind Checked and Unchecked exceptions?


    I would be interested in a definitive answer too.
    Except I just noticed that your example
    EmptyStackException is a wrong one. It is
    derived from RuntimeException and thereby
    unchecked.

    In principle I would say that everthing
    that is under the control of the program
    should be unchecked, because it goes wrong only
    in case of a bug, like NullPointerException,
    EmptyStackException or IllegalArgumentException.

    In contrast, there is no way to 100% avoid
    I/O errors, therefore an IOException is an expected,
    albeit annoying, state of the software and must
    be dealt with.

    However, the case is not so clear cut. Take, for
    example, URISyntaxException. You could say the program
    has full control, because it could check the syntax before
    using the URI. But then checking would always
    be done twice. First to ensure the syntax and then,
    naturally, when the URI is used.
    I fact URISyntaxException is a checked one.

    Harald.
     
    HK, May 6, 2005
    #3
  4. exquisitus

    Chris Uppal Guest

    exquisitus wrote:

    > My question is that why is EmptyStackException a checked exception (when
    > NullPointerException for example - is unchecked?). Surely, the
    > designation annot be arbitary?
    >
    > Could someone please provide a simpler/less ambiguous explanation of the
    > logic behind Checked and Unchecked exceptions?


    I think the logic is that checked exceptions are used for situations that you
    (the programmer) must expect to happen, and must therefore provide explicit
    code to handle. Unchecked exceptions are for cases that you can legitimately
    expect /not/ to occur in a deployed application (but may happen, may even
    happen a lot, during development).

    The canonical example of checked exceptions is opening a file. Obviously the
    programmer is not normally in a position to ensure that the file exists before
    opening it (and even if they were, then it's unlikely that they actually
    /would/ have checked), so clearly the program must contain code to handle the
    case where the file does not exist. Checked exceptions are used to force the
    programmer to consider that case.

    The canonical example of an unchecked exception is running off the edge of an
    array. That should not happen in working software, and so there's little to
    gain by forcing the programmer to handle the possibility (it still /is/ a
    possibility, of course) explicitly.

    Perhaps in some environments, for life- or mission- critical applications, it
    /would/ be reasonable to force the programmer to handle such cases explicitly.
    In applications where crashes are unacceptable no matter how severe the bug, or
    however unlikely it may be that there /is/ a bug, out-of-bounds exceptions
    might be better made checked.

    The general idea is that problems that indicate /bugs/ in the program are
    generally unchecked, whereas ones that reflect the generally unpredictable
    nature of the execution environment at runtime are generally checked. It's not
    a hard-and-fast distinction -- it is up to the judgement of the programmer to
    decide which category the problem falls into (and as indicated above, the
    category may depend on the application domain too).

    All this is somewhat confused by the facts that (a) for many classes of problem
    the most natural (default) response is to abort the application with an error
    message, and (b) for many classes of problem it would simply be too big a
    nuisance to force programmers to handle problems which might occur just about
    anywhere. So for the cases that fall into both categories, there's an
    additional pressure to make the exceptions unchecked, just to keep things
    simple. Out-of-memory exceptions are an example of this. That condition is
    not normally under the programmer's control, so you'd initially expect it to be
    a checked exception, but that would just be too much of a pain in the arse, and
    there's not normally much that one can do to recover from it (not locally to
    the point where it's thrown anyway), so out-of-memory is signalled by an
    unchecked exception.

    I think that NullPointerException illustrates both points quite well. Using a
    null reference (pointer) is normally an indication of a flaw in the program
    logic, and what's more a flaw that ought to be caught and eliminated by
    testing. It is /also/ a problem that could occur anywhere, and is rarely
    recoverable, so that's two reasons to make it unchecked.

    The example you gave of EmptyStackException is interesting. I think that
    there's a good case to be made that attempting to pop an empty stack is simply
    a programming error, and so that the exception should be unchecked. However it
    would seem that the authors saw it in a different light, presumably arguing
    that since any stack /can/ be empty, the popper of the stack should be forced
    to deal with the case where it /is/ in fact empty. I don't agree with their
    judgement on this.

    Personally, I think that too many 'standard' exceptions are checked. One
    reason is that exceptions tend to be grouped together by inheritance (for good
    reasons). E.g IOException and its subclasses. The problem with that is that
    checked/unchecked-ness does not naturally follow the same hierarchy -- or at
    least, it /should/ not follow the hierarchy, but unfortunately in Java it
    /does/ follow it. Resulting in too many exceptions being checked.

    -- chris
     
    Chris Uppal, May 6, 2005
    #4
  5. exquisitus wrote:
    ....
    > My question is that why is EmptyStackException a checked
    > exception (when NullPointerException for example - is
    > unchecked?). Surely, the designation annot be arbitary?
    >
    > Could someone please provide a simpler/less ambiguous
    > explanation of the logic behind Checked and Unchecked
    > exceptions?

    ....

    There is a trade-off between making sure the programmer
    plans for exceptions that may appear, and having too much
    explicit exception handling code.

    At one extreme, errors in JVM operations can happen
    anywhere. If java.lang.InternalError had to be caught or
    thrown everywhere it can happen, every single method would
    have to be declared to throw it. Even if you enclosed the
    body of the method in a try with a catch for it, it might
    happen in the processing of the try-catch itself. "throws
    InternalError" would add no information at all to the method
    declaration.

    Similarly, Most blocks of Java code can throw
    NullPointerException. If it were checked, almost every
    method would have to either catch it or be declared to throw it.

    At the other extreme, you have to be using very specific
    features to get, for example, a java.rmi.MarshalException.
    The caller of a method may not be expecting it to be thrown.
    Requiring it to be either caught or declared to be thrown in
    the very few methods in which it can happen adds real
    information that callers need.

    The exact boundary between what should be checked and what
    should be unchecked is difficult to set. Some cases are
    clearly on one side or the other, but other cases, closer to
    the boundary, seem quite arbitrary. I've extended
    RuntimeException when I was building some infrastructure
    that would be used throughout a program, and didn't want
    every method to have to be declared to throw its exceptions.

    Patricia
     
    Patricia Shanahan, May 6, 2005
    #5
    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. Wendy S
    Replies:
    0
    Views:
    1,851
    Wendy S
    Feb 18, 2004
  2. Ahmed Moustafa
    Replies:
    5
    Views:
    30,122
    Chris Smith
    Jul 14, 2004
  3. Lew
    Replies:
    15
    Views:
    788
  4. RVic
    Replies:
    19
    Views:
    1,447
  5. Joel Brabant

    checked AND unchecked

    Joel Brabant, Sep 22, 2003, in forum: ASP General
    Replies:
    2
    Views:
    171
    Ray at
    Sep 22, 2003
Loading...

Share This Page