Re: [Gnu-arch-users] Nit

[Mark A. Flacy]

>>>>> "Tom" == Tom Lord <address@hidden> writes:
Tom> 
Tom> Suppose I add a new throw to a function I maintain -- a new exception
Tom> that that function might throw.  Must I find all callers and make sure
Tom> that the new exception type won't screw them up?

The exceptions that a method throws are part of the signature of a method.
If you changed the return type or parameter list, you'd have the same
problem. 

Tom> 
Tom> For a while I was thinking it could all be done with just
Tom> declarations:
Tom> 
Tom>    Module A declares what exceptions it can generate.
Tom> 
Tom>    Module B uses A and declares what exceptions it thinks A can
Tom>         generate.
Tom> 
Tom> but that doesn't quite cut it.  Module A might generate a no_such_user
Tom> exception that I actually want to forward from some call sites into A
Tom> but not from others.   I think you really do want a per-call-site
Tom> enumeration of forwarded exceptions.

I'm afraid that I don't understand what you mean here.

>> We've beaten into most of our designers that if you aren't going
>> to do anything with the exception other than re-throw it, don't
>> catch the damned thing.  That's a runtime cost for no purpose.
Tom> 
Tom> If it were really an issue a compiler could do a good job with that.

Even if the compiler could do a good job with that type of code, it's still
useless noise in the source code that people have to read, understand, and
maintain.  

Tom> 
>> Java programmers should never catch Exception, print nothing and
>> do nothing with the exception.  Bad idea.
Tom> 
Tom> By default, they should catch Exception all over the place and abort
Tom> -- letting through only those exceptions they explicitly intend to.
Tom> The language should be extended with syntax to make that easy.

It already works that way in Java in that your throws list has to include
all exceptions can be thrown out of your method.  That includes exceptions
that bubble out from the methods that you call.

Java also has Error and RuntimeException exceptions that do not fall under
that requirement.  Errors are considered to be so fatal that there is
really nothing you can do to fix the problem that generated the error.
RuntimeExceptions are thrown by the JVM itself and are not part of your
API.

-- 
 Mark A. Flacy
 Any opinions expressed above are my own.  Any facts expressed above
 that you could detect means my weasel wording needs work.
 "Mercy to the guilty is treachery to the innocent." -- Anon