🚀 go-pugleaf

In article <1992Sep29.201603.19289@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>The more I think about it, the more I'm convinced that the uses for
>exception specifications are astonishingly restricted.  ...
...
>All of which leads me to believe that exception specifications are not
>really designed for the "general use" suggested in the last paragraph of
>commentary in ARM 15.5c.  That being the case, I'm tempted to suggest they
>be removed from the language.

I'd suggest studying the exception specifications in Modula-3 (latest
version).  Those are based on years of experience with Cedar and
Modula-2+, as well as a study of the effects of changing the exception
specification rules a large body of software already written in
Modula-2+.  Modula-3 has "object methods" that are more or less
equivalent to C++ "virtual member functions", so the rebinding problem
does not go away.

As I recall, the M-3 rules are:

   no specification is equivalent to "no exceptions raised".

   the set of exceptions raised is part of a function type.

   assignment to function variables and/or binding to object methods
   must be type correct (i.e., in V := F, the set of exceptions raised
   by F must be a subset of the exceptions raised by V -- this is
   checked statically).

   if a function F calls a function G, static checking may provide
   a warning if G can raise an exception not in the list of exceptions
   raised by F.  If this happens at run-time, the exception is
   converted to a "failure exception" that can only be caught by
        TRY ... EXCEPT ... ELSE <catch it here> END
   though finalization clauses will be executed.

I do not know how this corresponds to the exception specifications for
C++; I only know that these are sane and that they work.  The use of
objects types as exception types (as in C++) appears to be compatible
with this, and an improvement (at least in the case of single
inheritance).

David Chase
Sun

sdm@cs.brown.edu (Scott Meyers) writes:

>The more I think about it, the more I'm convinced that the uses for
>exception specifications are astonishingly restricted.  As I see it, you
>can't reliably put an exception specification on a function f if any of the
>following are true:
>
>    1.  A call to f might directly or indirectly lead to a call to g where
>        g lacks an exception specification.  A special case of this is
>        where g is a function written in another language, e.g., anything
>        in the standard C library.  Recall that functions without exception
>        specifications may throw anything.

What's wrong with
    extern "C" void g(void) throw ();
?

The grammar given in C++PL 2nd Ed. includes the non-terminal
"exception-specification", but this non-terminal is not refered to in the
rest of the grammar. Presumeably the production

    declarator : declarator ( argument-declaration-list ) cv-qualifier-list<opt>

should include exception-specification<opt> either before or after the
cv-qualifier-list<opt>, which would then mean that the above extern "C"
declaration is legal.

[By the way, which is it - before or after? Which of the following are legal:
	class X {
		void g() throw() const;		// before
		void f() const throw();		// after
	};
Or are both legal?]


>    2.  f is a template function.  In this case, f must be instantiated
>        using some unknown type T, and it is highly likey that f will
>        invoke some T-specific function (e.g. member function of class T).
>        However, there is no way to know what the exception specifications
>        are on the T-specific functions.
>
>    3.  f is a virtual function, because f may be redefined in a subclass
>        by some function f' that contains an incompatible exception
>        specification.  Recall that an exception specification is not part
>        of a function's type.
>
>The ARM refers to an exception specification as a "promise" (ARM 15.6.2c),
>but the above points make clear that this promise can't be given very
>often, or at least can't be relied upon very often.  Similarly, the
>discussion of why exception specifications are so lax is discussed in ARM
>15.5c.  The ARM also implies that special-purpose static analyzers would be
>required to do much of anything with exception specifications, especially
>in the presence of separate compilation.  (For example, if f contains an
>exception specification and calls virtual function g which also contains an
>exception specification, no warning can be issued if g is redefined by an
>incompatible g' in a derived class that is contained in a separate
>compilation unit.)

In C++PL 2nd Ed, BS says "An implementation may not reject an expression
simply because it _may_ throw an exception not specified in an exception-
specification of the function containing the expression; the handling
of violations of an exception-specification is done at run-time."

However this does NOT mean that the implementation may not give WARNINGS
in such cases. In particular I would not be satisfied with a compiler that
did not give me a warning any time that I 

	- call a function whose exception-specification is not a subset of
          the calling function's exception-specification;

	- redefine a virtual function with one whose exception-specification is
	  not a subset of the exception-specification of the base class's
	  function;

	- instantiate a template in such a manner as to cause either of the
	  above.

----------------------------------------------------------------------

If an exception is raised in a destructor while unwinding the stack
from a previous exception, then the function terminate() is called.

This means that in general, destructors should NEVER raise any exceptions.
I want to be able to put that exception specification on all my destructors.

	~X::X() throw() {...}

Furthermore, I want the compiler to check that at compile time, not at run-time.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

In article <lci3ptINN3m3@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
> ...
>I'd suggest studying the exception specifications in Modula-3 (latest
>version).  Those are based on years of experience with Cedar and
> ...
>I do not know how this corresponds to the exception specifications for
>C++; I only know that these are sane and that they work.  The use of
>objects types as exception types (as in C++) appears to be compatible
>with this, and an improvement (at least in the case of single
>inheritance).

I am afraid that distinguishing exceptions only by the type of the
'throw' expression is mostly overkill instead of improvement.
Suppose for instance that you have 20 distinct exceptions,
which only need to pass an integer's worth of information
to their handlers (or perhaps no data at all).
You have to declare a class for each of them.

John Skaller has remarked that the exception handling principle
requires run-time type information in the implementation,
a thing against which Bjarne Stroustrup has so steadfastly fought
all these years.  (Of course this does not necessarily mean that
the information would be available to the lowly programmers
to misuse.)

Obviously, inheritance between exceptions can be nice
in some situations.  That is one advantage of the C++ scheme.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------

In article <1992Sep29.201603.19289@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>The more I think about it, the more I'm convinced that the uses for
>exception specifications are astonishingly restricted.  As I see it, you
>can't reliably put an exception specification on a function f if any of the
>following are true:
>
>    1.  A call to f might directly or indirectly lead to a call to g where
>        g lacks an exception specification.  A special case of this is
>        where g is a function written in another language, e.g., anything
>        in the standard C library.  Recall that functions without exception
>        specifications may throw anything.
>
>    2.  f is a template function.  In this case, f must be instantiated
>        using some unknown type T, and it is highly likey that f will
>        invoke some T-specific function (e.g. member function of class T).
>        However, there is no way to know what the exception specifications
>        are on the T-specific functions.
>
>    3.  f is a virtual function, because f may be redefined in a subclass
>        by some function f' that contains an incompatible exception
>        specification.  Recall that an exception specification is not part
>        of a function's type.
>
>The ARM refers to an exception specification as a "promise" (ARM 15.6.2c),
>but the above points make clear that this promise can't be given very
>often, or at least can't be relied upon very often.  Similarly, the
>discussion of why exception specifications are so lax is discussed in ARM
>15.5c.  The ARM also implies that special-purpose static analyzers would be
>required to do much of anything with exception specifications, especially
>in the presence of separate compilation.  (For example, if f contains an
>exception specification and calls virtual function g which also contains an
>exception specification, no warning can be issued if g is redefined by an
>incompatible g' in a derived class that is contained in a separate
>compilation unit.)
>
>All of which leads me to believe that exception specifications are not
>really designed for the "general use" suggested in the last paragraph of
>commentary in ARM 15.5c.  That being the case, I'm tempted to suggest they
>be removed from the language.  For the specialized applications that can
>make use of them, an Anna-like annotation language seems more appropriate
>than actual language support within C++.
>
>Comments?
>
>Scott
>

	I agree that these situations are conceptually difficult.  Take a look
at section 15.6.2, though: the unexpected() function is called when a function
with an exception-specification throws an exception that is not listed in the
exception-specification.  Presumably, the runtime support for exceptions is
supposed to handle checking that the exception thrown is one that does not
violate the exception-specification.  I don't have any experience with
exceptions, so I'm not in a position to comment on the usefulness of this
construct.

First a little history.

When exceptions were accepted by
X3J16 there were some of us (including myself) who though (like Scott)
that exception specifications were useless.  However, there were
also many who felt they were essential to good programming.
The later included the only people (a medical software group at HP)
with experience using exceptions in C++. I asked them whether "out
of memory" had to always be included on their lists and they said
they didn't treat "out of memory" as an exception.

The people who liked failure clauses would have prefered that
the default condition be the same as an empty failure list.
That is if you don't say that a function can throw an exception
then it can't.  The result was a compromise, failure clasues are allowed,
but the default is to allow functions without them to throw any
exception.

-----
Now my opinion.

My impression is that if you design your system from scratch
(including all libraries) with failure clauses on all function
declarations and your compiler checks them for consistency
you gain some useful compile time type checking.  But in 
other circumstances there is little gained.

At the moment X3J16 is considering the implications of exceptions
for stream classes.  Some think that streams should only
be able to throw a particular kind of exception (tentatively
named ios::failure). Others (including myself) feel that a stream
should be able to throw an arbitrary exception. Remember, users
can define their own kinds of streambufs, so X3J16 can't know in advance
what kinds of conditions they might want to report.  

My intuition (not based on experience I confess) is that in
general it is more important to get specific information about
the conditions that caused an exception than it it to know that
it in occured in some stream operation. That is, it is better to
know that there was an "out of memory" or "database corruption" problem
than it is to know that there was a problem while doing a stream
operation.  This leads me to the conclusion that the iostream library
should not use failure clauses.
 
  -- Jerry Schwarz

Please. No followups about how throwing exceptions by streams
will break existing programs.  We're aware of that.  By default
streams will throw (almost) no exceptions and will catch any thrown
by a streambuf.

sakkinen@jyu.fi (Markku Sakkinen) writes:

>I am afraid that distinguishing exceptions only by the type of the
>'throw' expression is mostly overkill instead of improvement.
>Suppose for instance that you have 20 distinct exceptions,
>which only need to pass an integer's worth of information
>to their handlers (or perhaps no data at all).
>You have to declare a class for each of them.

Is this so difficult?

	class MyException : Exception {};

	struct MyIntException : Exception {
	    int value;
	    MyIntException(int value_) : value(value_) {}
	};

The amount of typing required does not seem to be excessive, IMHO.

>John Skaller has remarked that the exception handling principle
>requires run-time type information in the implementation,
>a thing against which Bjarne Stroustrup has so steadfastly fought
>all these years.  (Of course this does not necessarily mean that
>the information would be available to the lowly programmers
>to misuse.)

The run-time type information need only be supplied for objects which are
actually thrown, not for all objects.

------------------------------------------------------------------------

One possible implementation is as follows: for each class that may be thrown,
store the name of the class, together with pointers to all the classes it
is derived from (if any):

	struct __Type {
		const char *type_name;
		int num_base_classes;	  // will be >1 for multiple inheritance
		__Type *base_classes[1];  // we're using the "struct hack" for
					  // efficiency :-)
	};

So everytime we see a throw(x) statement, where x is an object of class X,
we generate the type info for X and all it's base classes, and store these in
global constants __type_info_for_class_X etc.

When an exception is thrown, we need to store both the object thrown and also
it's type info:

	void* __exception_object;	// pointer to the object thrown
	__Type* __exception_type;	// run-time type info

The code generated for the throw statement itself looks like:
	__exception_object = new X(x);
	__exception_type   = &__type_info_for_class_X;
	unwind_stack();

Then the code generated for a statement like
	catch(Matherr mm) { ... }
will look like
	if (__matches_type("Matherr", __exception_type)) {
	    Matherr& mm = *(Matherr *)__exception_object;
	    ...
	}
where __matches_type just does string comparison on the type names:

	int __matches_type(const char *type_name, Type *type) {

	    // does it match the class name?
	    if (strcmp(type_name, type->type_name) == 0)
		return TRUE;

	    // does it match with any of the parent classes?
	    for (int i = 0; i < type->num_base_classes)
		if (__matches_type(type_name, type->base_classes[i])
		    return TRUE;

	    // otherwise, no match found
	    return FALSE;
	}

Have I confused you enough already?
Anyway, what I was trying to point out was that it really isn't that
complicated: exception handling only requires run-time type info for objects
that are actually throw, and run-time type identification can just involve
simple string comparisons.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

In article <1992Sep29.201603.19289@cs.brown.edu>, sdm@cs.brown.edu (Scott Meyers) writes:
|> The more I think about it, the more I'm convinced that the uses for
|> exception specifications are astonishingly restricted.  As I see it, you
|> can't reliably put an exception specification on a function f if any of the
|> following are true:
|> 
|>     1.  A call to f might directly or indirectly lead to a call to g where
|>         g lacks an exception specification.  A special case of this is
|>         where g is a function written in another language, e.g., anything
|>         in the standard C library.  Recall that functions without exception
|>         specifications may throw anything.
|> 
|>     2.  f is a template function.  In this case, f must be instantiated
|>         using some unknown type T, and it is highly likey that f will
|>         invoke some T-specific function (e.g. member function of class T).
|>         However, there is no way to know what the exception specifications
|>         are on the T-specific functions.
|> 
|>     3.  f is a virtual function, because f may be redefined in a subclass
|>         by some function f' that contains an incompatible exception
|>         specification.  Recall that an exception specification is not part
|>         of a function's type.
|> 

I don't think (1) and (2) are real problems; the funtion f should catch all
exceptions except the ones it lists in its exception specification.

(3) is a real problem; either the rules on exception specifications as part
of the function signature need to be changed (a la Modula-3), or they won't
be very safe.  I'd rather see them done as in Modula-3 (but still allow the
default -- no specification -- to allow all exceptions to be thrown).

-- 
Matt Holiday                                      #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX

In article <1992Sep30.205656.10646@lucid.com>, jss@lucid.com (Jerry Schwarz) writes:
|> 
|> At the moment X3J16 is considering the implications of exceptions
|> for stream classes.  Some think that streams should only
|> be able to throw a particular kind of exception (tentatively
|> named ios::failure). Others (including myself) feel that a stream
|> should be able to throw an arbitrary exception. Remember, users
|> can define their own kinds of streambufs, so X3J16 can't know in advance
|> what kinds of conditions they might want to report.  
|> 
|> My intuition (not based on experience I confess) is that in
|> general it is more important to get specific information about
|> the conditions that caused an exception than it it to know that
|> it in occured in some stream operation. That is, it is better to
|> know that there was an "out of memory" or "database corruption" problem
|> than it is to know that there was a problem while doing a stream
|> operation.  This leads me to the conclusion that the iostream library
|> should not use failure clauses.

One thing that bugs me about having "lots" of exception types that could be
thrown is the degree of coupling that will result between parts of the program.

If an object can throw 18 exception types, then clients will need to understand
all those types, and their implications -- and perhaps then, something of the
internal workings of that object, in order to understand how to respond to a
particular exception.

It might be better to cause the functions in the objects interface (the top
level functions of the object) to throw only a limited set of exceptions, perhaps
only one, and handle all other exceptions themselves (print an error message or
log, take some constructive action, etc.).  The client's response to failure
of an object might be to destroy and recreate the object, and reattempt the
operation, or call a "recover" function in that object, etc.

There is a measure of philosophical difference here.  If all parts of the program
are written by the same team, then the team can determine the safe degree of 
coupling between objects and their clients.  On the other hand, if a program is
to be created from reusable (perhaps third-party) software libraries, then coupling
should be minimized -- otherwise, why use objects at all?

-- 
Matt Holiday                                         #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX

In article <1992Sep30.205656.10646@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>At the moment X3J16 is considering the implications of exceptions
>for stream classes.  Some think that streams should only
>be able to throw a particular kind of exception (tentatively
>named ios::failure). Others (including myself) feel that a stream
>should be able to throw an arbitrary exception. Remember, users
>can define their own kinds of streambufs, so X3J16 can't know in advance
>what kinds of conditions they might want to report.  
>
>My intuition (not based on experience I confess) is that in
>general it is more important to get specific information about
>the conditions that caused an exception than it it to know that
>it in occured in some stream operation. That is, it is better to
>know that there was an "out of memory" or "database corruption" problem
>than it is to know that there was a problem while doing a stream
>operation.  This leads me to the conclusion that the iostream library
>should not use failure clauses.

It seems like a compromise -- making ios::failure into a base class
from which other more specific exception types can be derived -- would
be the best approach.  Application code that can do something useful
with specific exceptions can then arrange to catch each one
individually, while code that cares only that an exception was thrown
but does not wish to catch each different type can arrange to catch
only the base class.

-steve
-- 
Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.

Matt> If an object can throw 18 exception types, then clients will need
Matt> to understand all those types, and their implications -- and
Matt> perhaps then, something of the internal workings of that object,
Matt> in order to understand how to respond to a particular exception.

By carefully deriving exception types, the clients needn't worry about
details they really don't understand or care about.

Matt> It might be better to cause the functions in the objects
Matt> interface (the top level functions of the object) to throw only a
Matt> limited set of exceptions, perhaps only one, and handle all other
Matt> exceptions themselves (print an error message or log, take some
Matt> constructive action, etc.).

Rather, let them throw any number of exceptions, but make sure the
exception types have a limited number of distinct base classes. The
ability to derive exception types is the very feature that makes C++
exceptions superior to -- say, Ada's. Client code can catch them with
the accuracy it needs to instead of what the library says.


==pena
--
Olli-Matti Penttinen <pena@niksula.cs.hut.fi>
Lehdesniityntie 3 F 91
00340 HELSINKI                     "When in doubt, use brute force."
tel. + 358 0 1399 0110                -- Ken Thompson

In article <1992Oct01.143355.27847@bnr.ca>, Matthew Holiday writes:

|> In article <1992Sep30.205656.10646@lucid.com>, jss@lucid.com (Jerry
|> Schwarz) writes:

|> |> At the moment X3J16 is considering the implications of exceptions
|> |> for stream classes.  Some think that streams should only
|> |> be able to throw a particular kind of exception (tentatively
|> |> named ios::failure). Others (including myself) feel that a stream
|> |> should be able to throw an arbitrary exception. Remember, users
|> |> can define their own kinds of streambufs, so X3J16 can't know in advance
|> |> what kinds of conditions they might want to report.  
|> |> 
|> |> My intuition (not based on experience I confess) is that in
|> |> general it is more important to get specific information about
|> |> the conditions that caused an exception than it it to know that
|> |> it in occured in some stream operation. That is, it is better to
|> |> know that there was an "out of memory" or "database corruption" problem
|> |> than it is to know that there was a problem while doing a stream
|> |> operation.  This leads me to the conclusion that the iostream library
|> |> should not use failure clauses.

|> One thing that bugs me about having "lots" of exception types that
|> could be thrown is the degree of coupling that will result between
|> parts of the program.

|> If an object can throw 18 exception types, then clients will need to
|> understand all those types, and their implications -- and perhaps
|> then, something of the internal workings of that object, in order to
|> understand how to respond to a particular exception.

|> It might be better to cause the functions in the objects interface
|> (the top level functions of the object) to throw only a limited set of
|> exceptions, perhaps only one, and handle all other exceptions
|> themselves (print an error message or log, take some constructive
|> action, etc.).  The client's response to failure of an object might be
|> to destroy and recreate the object, and reattempt the operation, or
|> call a "recover" function in that object, etc.

|> There is a measure of philosophical difference here.  If all parts of
|> the program are written by the same team, then the team can determine
|> the safe degree of coupling between objects and their clients.  On the
|> other hand, if a program is to be created from reusable (perhaps
|> third-party) software libraries, then coupling should be minimized --
|> otherwise, why use objects at all?

This leads to my basic premise.

Objects in a general library should not throw exceptions at all.  The
how and what of exception handling is *always* application specific,
and if a library like the iostream starts throwing exceptions, it
forces *all* applications that use it into its mould.

The solution I prefer is call-back functions.  The default failure
action is always to terminate the program with an error message.
Since this occurs near the point of the error, the error message can
actually be quite meaningful.  In failsafe applications, the user
replaces the default error function with one of his own, which may
very well (probably will) throw an exception.  This will be an
exception designed by the user however, and not one imposed by the
library.  The choice of whether one or many exception classes, etc.,
and in what class hierarchy they are, can then be made in an
application specific manner by the user.
--
James Kanze                     GABI Software, Sarl.
email: kanze@us-es.sel.de       8 rue du Faisan
                                67000 Strasbourg
                                France

In article <KANZE.92Oct7151332@slsvdnt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
|> This leads to my basic premise.
|> 
|> Objects in a general library should not throw exceptions at all.  The
|> how and what of exception handling is *always* application specific,
|> and if a library like the iostream starts throwing exceptions, it
|> forces *all* applications that use it into its mould.
|> 
|> The solution I prefer is call-back functions.  The default failure
|> action is always to terminate the program with an error message.
|> Since this occurs near the point of the error, the error message can
|> actually be quite meaningful.  In failsafe applications, the user
|> replaces the default error function with one of his own, which may
|> very well (probably will) throw an exception.  This will be an
|> exception designed by the user however, and not one imposed by the
|> library.  The choice of whether one or many exception classes, etc.,
|> and in what class hierarchy they are, can then be made in an
|> application specific manner by the user.

Sorry to waste bandwidth on such a short follow-up, but I just want to
re-enforce James' premise and his call-back solution.  Let the client of a
general library choose what type of action to take for an error in a
general-purpose library.  Using this mechanism for the default allocator
would allow a GUI-based application to automatically display an "Out of
Memory" message and terminate, for example, rather than raise an exception.

-- 

- Pablo

------------------------------------------------------------------------
Pablo Halpern             (617) 290-3542
HP Waltham                pabloh@hpwarq.wal.hp.com

I am self-employed, so my opinions *do* reflect those of my employer.
However, they may not reflect the opinions of my client.
------------------------------------------------------------------------