Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!psuvax1!brutus.cs.uiuc.edu!zweig
From: zweig@brutus.cs.uiuc.edu (Johnny Zweig)
Newsgroups: comp.lang.c++
Subject: Re: Exception Handling in C++
Message-ID: <1990Apr13.192428.17008@brutus.cs.uiuc.edu>
Date: 13 Apr 90 19:24:28 GMT
References: <680@mead.UUCP> <1990Apr13.034540.10997@brutus.cs.uiuc.edu>
Sender: news@brutus.cs.uiuc.edu
Reply-To: zweig@cs.uiuc.edu
Distribution: usa
Organization: U of Illinois, CS Dept., Systems Research Group
Lines: 37

zweig@cassius.cs.uiuc.edu (Johnny Zweig) writes:
>....
>There is also a way that a function can declare what exceptions it might
>raise to allow type-safe exception handling (whether functions that lack
>a throw-clause are saying they can generate any exception or no exception
>is unclear to me; it makes a big difference in what you can do and there
>is a nice religious safety vs. flexibility argument associated with
>which it is -- I'll read the paper and post which it is if noone else
>comments).

Because we want C++ programs to be able to call C functions and to keep
the programmer from having to scribble all over everything to have an
exception be passable through all the levels of indirection (i.e. have main()
catch some scary exception that is raised by some low-level math routine) the
decision was made that undecorated functions can throw any exception.

Please note that the syntax given in the paper was changed to that shown
above (the paper says catch(f) raises f, rather than throw()...).  An errata
sheet was handed out at the conference but I doubt the proceedings will be
corrected before copies go out to your local library.

Also, the paper goes into some gibberish (no offense intended to Mr.
Stroustrup, but this section was smoking something) about whether an exception
is an object or a class.  An exception is an object and a handler takes a 
(possibly anonymous) exception as an argument.  The fact that I can say
"catch(Foo){" to catch any object of type Foo (or a subtype of Foo) and be
unable to refer to it is syntactically odd but not tricky to think about.
The paper talks about being able to raise a pointer to an object as if it
were something scary -- I think it looks like function-calling and I always
think of functions as taking objects (though pointers aren't objects in
C++...sigh!).  I would welcome anyone who can explain this to me. It seems
to be because you can't get the right flavor of virtual function when you
pass an object (as opposed to a pointer to an object) -- so you can pass
an object or a pointer to a new object (by saying "throw(new Foo);") but
it is totally ganjafied to say it is both an object and a class.

-Johnny Exceptional