Re: [Gnu-arch-users] Nit

[Dustin Sallings]

On Tuesday, Oct 21, 2003, at 09:11 US/Pacific, Tom Lord wrote:

> > From: "Mark A. Flacy" <address@hidden>
>
> > Because many authors will think that their software layer should throw
> > certain exceptions and only those exceptions.
>
> That's a good principle but it's only half the story.
>
> Each call should only _expect_ certain exceptions and no exception
> should get past a call-site that doesn't explicitly say it's expected.
>
> Suppose I add a new throw to a function I maintain -- a new exception
> that that function might throw.  Must I find all callers and make sure
> that the new exception type won't screw them up?

[lots of stuff about catching all possible exceptions and passing ones 
you don't intend to handle]

	The part that you're missing here is that exceptions are part of the 
API of a method call in java.  If you add a new exception type, code 
that ignores it will fail to compile.

	I think this is part of the confusion regarding exceptions.  Languages 
that don't support compile-time checked exceptions have frightening 
side-effects of using exceptions.  Those seem to be the problems you're 
discussing.  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.

	Java also has unchecked exceptions, but those are things that your 
application isn't expected to be able to reasonably handle.  This is 
for things like out of memory conditions, failure to load a class, 
etc...  You can still catch these, but you aren't required to declare 
them, only ``normal'' stuff (stack overflow, IO error, sql 
exception...the likely stuff).

--
Dustin Sallings