Re: Exceptions

[Tim Vernum]

>Urg... doesn't Java do that?

Yes.
C++ has the same feature, but for backwards compat reasons (I think) doesn't 
enforce it, which makes it close to useless.

> I've never used java, so I can't say much about
>how having to declare all exceptions turns out in practice, but it seems like
>it would lead to "cascading verbiage" where each method may throw any
>exception any methods it call may throw, which encourages people to handle
>exceptions immediately, which defeats the whole point of exceptions in the
>first place.

In my experience (and I work in a small team compose mainly of experienced 
developers) it works quite well.

What happens is you will code your method, and then compile it, and the 
compiler tells you all the exceptions that could have been raised in your code, 
but you didn't specify.
In each case you then have to question:
 * Should I catch it?
 * If I catch it, what can I do to recover?
 * Should I throw it on?
 * Will the client of my class be able to make sense of it?

Often catching the exception is a VERY good thing to do.

eg, I have an interface (absract class) that provides some form of persistence. 
I might implement it with flat files, or with a database, or some other way. 
All the person that uses this interface knows, is that if they call my 
"SaveObject" method, then the object will be saved, and can be restored with 
"RestoreObject".
If I write code that hits a flat file, then I shouldn't throw file-system 
exception on to the client, unless I expect them to be fatal.
My client doesn't know that I use a flat file. They shouldn't have to deal with 
 file-system problems.
If they're not going to catch a file exception, then it will abort the program, 
which may not be necessary.

If you don't declare your exception list, then you force the client to know 
about your implementation in order to know what sorts of exception to expect.

Java actually has two types of exceptions, "normal" exceptions, and "runtime" 
exceptions. Runtime exceptions are things like "array-index-out-of-bounds" and 
you don't need to list these, because it is assumed that 90% of methods will 
have the potential to raise these, and so it is assumed that any method can 
raise a runtime exception.

Exceptions are important.
Forcing you to list them is good because it forces you to think about them.

What I would like is a way to "morph" an exception.

So if I get a file-system exception, I can morph it into a "persistence 
exception" without losing any of the information stored in the orignal 
exception, but making it into a form that can be managed by my client.
Probably some form of "chaining" would do the trick.

>Can't that sort of thing be inferred by the compiler?

Yes. 
And so can the return type.
But we still declare it.
 

>> (3) Throw a well-defined exception.
>
>Obviously this is the one I prefer :)

Part of being well-defined is providing a language level list of all exceptions 
that you can throw.

>Only if the user wants it to be a non-fatal error.  Many errors *are* fatal.
>Assertions are among them, but there a lot of other cases.  Those exceptions
>are usually handled by the runtime, which hopefully prints the name and value
>of the exception and a stack trace if debugging is on.  Isn't that what
>exceptions are all about? :)

Not always.
I don't want my text-editor to shutdown if it gets an exception while trying to 
save.
If (eg) NFS failed on me, and that caused an exception, then I can still save 
to a local disk, or copy me file to the clipboard.
Exceptions often abort the "current operation", but not all applications are 
single operation.

--
   Tim Vernum   | I believe that every right implies a responsibility; 
----------------| every opportunity, an obligation; 
address@hidden | every possession, a duty. - John D. Rockefeller