Re: Exceptions

[Norbert Nemec]

On Sat, Oct 14, 2000 at 05:05:54PM -0500, Tim Vernum wrote:
> 
> >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.

That's correct. The fear of accumulation of exception in the Java model 
is unnecessary, I think. P.e.: If I have a class handling File-IO, 
there is no reason why it should throw any Array-Exceptions, just 
because it uses an array somewhere in the implementation. Of course 
asynchronous exceptions (or however they are called in Java) are a 
different matter, but they have a completely different purpose. 
(Assertion-Exceptions might be of that category in Sather. Usually, 
there is no point in checking them, but in a large modular project, it 
might be a good idea to protect the parts against each other.


> 
> 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.

At the moment, Sather exceptions carry no information that could be 
"morphed" in a useful way. If there once is a concept for exceptions, 
it must, of course be considered, that the information can be retrieved 
completely and put into a new exception. I see no problem in that.

> >Can't that sort of thing be inferred by the compiler?
> 
> Yes. 
> And so can the return type. But we still declare it.

One could create a tool that extracts the necessary information and put 
it into the source...

Ciao,
Nobbi

-- 
-- ______________________________________________________
-- JESUS CHRIST IS LORD!
--          To Him, even that machine here has to obey...
--
-- _________________________________Norbert "Nobbi" Nemec
-- Hindenburgstr. 44  ...  D-91054 Erlangen  ...  Germany
-- eMail: <address@hidden>   Tel: +49-(0)-9131-204180