Re: [Gnu-arch-users] Nit

[zander]

On Tue, Oct 21, 2003 at 11:02:20AM -0700, Tom Lord wrote:
>     > If the language only has unchecked exceptions (C#, OCaml, 
>     > etc...) then you have to really know what can go wrong whenever you 
>     > call a function, and you've got to hope it doesn't change.  IMO, 
>     > checked exceptions are necessary for a stable API.
> 
> Checked exceptions, in the Java sense, are too weak to accomplish your
> goal.   They check that all of your callers who might forward your
> exceptions are declared to forward all the types of exceptions you
> might generate -- but they fail to check that at each call-site in
> your callers, the forwarding is intentional.    As the example above
> illustrates, code can easily change under Java-style checking and lead
> to the wrong handler being invoked.

While this is quite true; in practice this is less drastic then you see
it.
As was pointed out before, throws clauses are part of the API. Changing
the throws clause will break compilation just like changing an argument
will. Hence; it is breaking your API.

The effect will be that the exception will propagate up the call stack
and reach someone that catches it. If nobody does; the thread will die
with the error message from the exception.

All exceptions can be caught by a couple of wildcards; Exception is a
wildcard for all checked exceptions, Error is a wildcard for all unchecked
exceptions, and Throwable is a wildcard for all.
If I call some foreign application that I have no idea how well it might
behave I am totally secure by catching a Throwable, and simply logging
it and shoot the sucker down afterwards.

> This doesn't look any better to me than the possibility that a C
> programmer might call malloc without checking for 0 or open without
> checking for -1.  If anything, the false sense of security you get
> from an exception checker that claims to "reduce the number of
> exceptions which are not properly handled" makes Java exceptions the
> more dangerous approach.

You miss the notion that an open will NOT return when an exception is
thrown.  So checking if the file is actually there is pointless.

This won't compile for instance:
    File myFile;
    try {
        myFile = new File("bla");
    } catch(IOException e) { }
    myFile.close();

I get an error from my compiler that myFile (the last line) might not have
been filled, so it can't be used.

> The bottom line: really robust code needs to check for every possible
> error condition at every call.  Everything else is mostly just a
> choice of syntax and implementation details.

I hoped you will take a longer look at exception programming (at least in
java since it does not have problems like missing free's) before you make
such a statement since many people disagree with you.  And like me they
design systems using exceptions daily.

-- 
Thomas Zander

pgpQJ1pDafC3S.pgp
Description: PGP signature