Re: Catching exceptions that are never thrown

Discussion in 'Java' started by Adam Maass, Jul 15, 2003.

  1. Adam Maass

    Adam Maass Guest

    "Joona I Palaste" <> wrote:
    > Sometimes Java syntax can get downright nasty. Look at this example
    > code:
    >
    > public interface IFoo
    > {
    > public void doIt() throws Exception;
    > }
    >
    > public class Foo implements IFoo
    > {
    > public void doIt() throws Exception
    > {
    > }
    > }
    >
    > public class Bar
    > {
    > public void doItToo()
    > {
    > IFoo foo = new Foo();
    > foo.doIt();
    > }
    > }
    >
    > Bar won't compile, because its doItToo() method calls the doIt()
    > method in IFoo, but neither catches or throws the Exception that doIt()
    > claims to throw. *BUT!* The implementation of IFoo, Foo, never ever
    > throws that Exception in its implementation of doIt().
    > This kind of thing can get severely frustrating in production code.
    > I suppose it would be too much to ask for the Java compiler to check
    > the code and see if it is *guaranteed* that the implementation of IFoo
    > was one that doesn't throw an Exception from doIt() - this would be
    > *VERY* expensive - so why not have some kind of new keyword that
    > constitutes some kind of dummy "try-catch" block? For example:
    >
    > force foo.doIt();
    >
    > would mean that foo.doIt() should be called, and if it really threw
    > that Exception, the whole JVM could crash for all I care.
    >
    > What do you others think of this idea?
    >


    Bad Idea. The exception declaration is in the interface for a good reason.
    Just because you know that the particular implementation you're using will
    never throw that exception is no reason to write code that ignores the
    exception. [What happens when some other implementation is substituted for
    the one you're using at a later date?]

    If it's your own code, modify the interface so that the exception isn't in
    the interface.
     
    Adam Maass, Jul 15, 2003
    #1
    1. Advertising

  2. Adam Maass <> scribbled the following:
    > "Joona I Palaste" <> wrote:
    >> Sometimes Java syntax can get downright nasty. Look at this example
    >> code:
    >>
    >> public interface IFoo
    >> {
    >> public void doIt() throws Exception;
    >> }
    >>
    >> public class Foo implements IFoo
    >> {
    >> public void doIt() throws Exception
    >> {
    >> }
    >> }
    >>
    >> public class Bar
    >> {
    >> public void doItToo()
    >> {
    >> IFoo foo = new Foo();
    >> foo.doIt();
    >> }
    >> }
    >>
    >> Bar won't compile, because its doItToo() method calls the doIt()
    >> method in IFoo, but neither catches or throws the Exception that doIt()
    >> claims to throw. *BUT!* The implementation of IFoo, Foo, never ever
    >> throws that Exception in its implementation of doIt().
    >> This kind of thing can get severely frustrating in production code.
    >> I suppose it would be too much to ask for the Java compiler to check
    >> the code and see if it is *guaranteed* that the implementation of IFoo
    >> was one that doesn't throw an Exception from doIt() - this would be
    >> *VERY* expensive - so why not have some kind of new keyword that
    >> constitutes some kind of dummy "try-catch" block? For example:
    >>
    >> force foo.doIt();
    >>
    >> would mean that foo.doIt() should be called, and if it really threw
    >> that Exception, the whole JVM could crash for all I care.
    >>
    >> What do you others think of this idea?


    > Bad Idea. The exception declaration is in the interface for a good reason.
    > Just because you know that the particular implementation you're using will
    > never throw that exception is no reason to write code that ignores the
    > exception. [What happens when some other implementation is substituted for
    > the one you're using at a later date?]


    > If it's your own code, modify the interface so that the exception isn't in
    > the interface.


    I agree to this reasoning, but here's a more subtle example.

    public interface IFoo
    {
    public void doIt(Object arg) throws Exception;
    // arg must never be null!
    }

    public class Foo implements IFoo
    {
    public void doIt(Object arg) throws Exception
    {
    if (arg == null) {
    throw new Exception("arg cannot be null!");
    }
    }
    }

    public class Bar
    {
    public void doItToo()
    {
    IFoo foo = new Foo();
    foo.doIt(new Object());
    }
    }

    Bar won't compile here either, because it doesn't catch or throw that
    Exception. Now "new Object()" will never be null, or there is something
    hopelessly wrong. But Java forces me to indirectly check for its nullity
    anyway. I guess *HERE* I could say:

    force foo.doIt(new Object());

    and leave the JVM to crash if for some reason the doIt() method really
    does throw that Exception.

    This kind of situation arises a heck of a lot in the current code I am
    writing in the project we are doing for our customer.

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "It sure is cool having money and chicks."
    - Beavis and Butt-head
     
    Joona I Palaste, Jul 15, 2003
    #2
    1. Advertising

  3. Adam Maass

    Daniel Dyer Guest

    On Tue, 15 Jul 2003 13:45:46 -0700, Adam Maass
    <> wrote:

    > The compiler won't make you write handlers for unchecked exceptions. And
    > generally, you shouldn't handle them anyway. They indicate conditions
    > that
    > are really beyond control (OutOfMemoryError, for example), or should be
    > fixed before the code goes to production (as in
    > ArrayIndexOutOfBoundsException).


    I agree with what you said, but it's worth pointing out that
    OutOfMemoryError is not an Exception (checked or unchecked) but an Error.
    So you can view your two categories as Errors (conditions beyond control)
    and RuntimeExceptions (bugs in the code).


    --
    Daniel Dyer
    Empathy Software (http://www.empathysoftware.com)


    -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
    http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
    -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
     
    Daniel Dyer, Jul 16, 2003
    #3
  4. Adam Maass

    Adam Maass Guest

    "Daniel Dyer" <> wrote:
    > On Tue, 15 Jul 2003 13:45:46 -0700, Adam Maass
    > <> wrote:
    >
    > It's worth pointing out that
    > OutOfMemoryError is not an Exception (checked or unchecked) but an Error.
    > So you can view your two categories as Errors (conditions beyond control)
    > and RuntimeExceptions (bugs in the code).
    >
    >


    This is true. But Exception, the class, is a distinct thing from exception,
    the concept. The concept of exception maps more closely to the Java class
    called Throwable than it does to the class actually called Exception. When I
    wrote:

    = The compiler won't make you write handlers for unchecked exceptions. And
    = generally, you shouldn't handle them anyway. They indicate conditions that
    = are really beyond control (OutOfMemoryError, for example), or should be
    = fixed before the code goes to production (as in
    = ArrayIndexOutOfBoundsException).

    I was using "exception" to mean the concept, not the class.


    There really are three categories:

    Errors: beyond recoverable control in the immediate program, usually VM
    conditions.

    RuntimeException: also beyond recoverable control in the immediate program.
    Coding error.

    Exception: within recoverable control in the immediate program -- program
    can attempt something else.



    Things like nullity tests and bounds-checking should result in
    RuntimeExceptions (which are unchecked and thus do not need to be put into
    method signatures) while things like "can't store that file there" should be
    checked exceptions so that the user can choose do to something else in that
    case.


    I think the exception hierarchy is a little messed up. If I had my druthers,
    I would re-write it like this (replacing the current class Throwable with my
    new class Exception):

    Exception
    UncheckedException
    Error
    RuntimeException
    CheckedException
    ApplicationException

    and document that custom exceptions are expected to be subclasses of
    ApplicationException or RuntimeException. Maybe even enforce it by making
    the constructors in the other classes not public.

    I might even require a special syntax for catch-clauses that wanted to catch
    things other than CheckedException or its subclasses.


    -- Adam Maass
     
    Adam Maass, Jul 16, 2003
    #4
  5. In news:,
    Adam Maass <> spoke unto us:

    ....[john jacob jingleheimer snip]...


    > There really are three categories:
    >
    > Errors: beyond recoverable control in the immediate program, usually
    > VM conditions.
    >
    > RuntimeException: also beyond recoverable control in the immediate
    > program. Coding error.



    ....[here a snip, there a snip, everywhere a snip-snip]...

    I understand what you (and the JSL) are saying here, but I have to chime in
    that IMO the RuntimeException much more the notion of:

    Thou don't /have/ to supply an error handler

    than

    Thou shouldn't supply an error handler
     
    Thomas G. Marshall, Jul 16, 2003
    #5
  6. Adam Maass

    Sudsy Guest

    Thomas G. Marshall wrote:
    <snip>
    > ...[here a snip, there a snip, everywhere a snip-snip]...
    >
    > I understand what you (and the JSL) are saying here, but I have to chime in
    > that IMO the RuntimeException much more the notion of:
    >
    > Thou don't /have/ to supply an error handler
    >
    > than
    >
    > Thou shouldn't supply an error handler
    >


    I agree completely. When parsing numbers, for example, I often use
    something like this:

    int value = -1;
    try {
    value = Integer.parseInt( s );
    }
    catch( NumberFormatException e ) {
    // tell the user off
    }

    A perfectly good reason for catching a RuntimeException, IMHO.
     
    Sudsy, Jul 22, 2003
    #6
    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. Mike Schilling
    Replies:
    2
    Views:
    353
    Mike Schilling
    Jul 16, 2003
  2. Soren Kuula
    Replies:
    1
    Views:
    460
    Henry S. Thompson
    Dec 1, 2005
  3. Kevin
    Replies:
    4
    Views:
    432
    Irrwahn Grausewitz
    Oct 17, 2003
  4. yawnmoth
    Replies:
    97
    Views:
    4,735
    Bent C Dalager
    Feb 27, 2009
  5. John Harkin
    Replies:
    0
    Views:
    152
    John Harkin
    Aug 18, 2004
Loading...

Share This Page