🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

3 total messages Started by dak Wed, 15 Nov 1995 18:03
Re: ubiquitous exception specs?
#2614
Author: dak
Date: Wed, 15 Nov 1995 18:03
42 lines
2273 bytes
In a previous artivle, Herb Sutter wrote:

>
> In article <9511120523.14310@mulga.cs.mu.OZ.AU>,
>    fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:
> >herbs@interlog.com (Herb Sutter) writes:
> >>While we're on the subject of exception handling, is there any technical
> >>reason not to have an exception spec on every member function of every
> class?
> >
> >There is at least one technical reason - it won't work with template
> >classes.  Consider, for example, the member functions of the STL
> >collection classes.  What exception specification should they have?
>
> Hmm... good point, but while this is a good argument in the case of collection
> classes, is it necessarily true of all template classes?
>

Why shouldn't templates have exception specified ?  Saying that it depends on
the types used in the template instance seems gibberish to me: you could say
the same for any class that use any other class (eitehr publicly or in its
implementation).

The real problem is exception enforcement: a function without a throw clause
can throw any exception, but then again, maybe not. Thus the compiler cannot
enforce anything on such code. This is true for any class, and each time the
designer must decide if he wish to enforce a particular exception or let the
door open for anything to happen.

The fact that types used in template are unknown and may throw any exception
doesn't change that fact: either you put a catch expression on each usage of
the sub-type, or let the unexpected exception handler do the job or you don't
specify exceptions that can be thrown.
-
the biggest problem with C++ is its popularity.                    dak@cae.ca


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Re: ubiquitous exception specs?
#2694
Author: Fergus Henderson
Date: Tue, 21 Nov 1995 16:02
43 lines
2672 bytes
dak <pierreba@poster.cae.ca> writes:

>Why shouldn't templates have exception specified ?  Saying that it depends on
>the types used in the template instance seems gibberish to me: you could say
>the same for any class that use any other class (eitehr publicly or in its
>implementation).

Part of the problem is that the C++ language is not powerful enough to
express the right exception specifications for even simple templates.
For example, what should the exception specification for the following
template be?

	template <class T> T add3 (T a, T b, T c) { return a + b + c; }

Using exception specifications is a trade-off, just like using
a strongly typed language is a trade-off.  Strong types are great
if the type system is powerful enough (e.g. it includes templates
or some equivalent functionality), but if it is not, they can
be a real straight-jacket.

A coding standard which required the use of exception specifications
on all templates would also be a straight-jacked, because it would
make it difficult or impossible to write/use a lot of simple and useful
templates.

Another part of the problem is that even if the C++ language
was powerful enough to express appropriate exception specifications for
templates, the declarations might be complex, long-winded, and thus
might in the end not be worth the effort.  The additional development
and maintenance cost of writing and maintaining the declarations might
not be worth whatever benefit it buys you in terms of preventing
unexpected exceptions.  In the case of non-template functions, the
declarations are usually simpler, and so the trade-off is different -
using exception specifications might be worthwhile in the simple case,
but might not be worthwhile in the case of templates.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Re: ubiquitous exception specs?
#2683
Author: Pulkkinen Esa
Date: Thu, 23 Nov 1995 22:44
36 lines
2305 bytes
In article <9532600.2461@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>Part of the problem is that the C++ language is not powerful enough to
>express the right exception specifications for even simple templates.
>For example, what should the exception specification for the following
>template be?
>
>	template <class T> T add3 (T a, T b, T c) { return a + b + c; }
>
I think you could in principle declare the exception specification as
typedefs, and then refer to the new types in the exception specification.
For example: (assuming all functions have a corresponding function object)

template <class Function> class exception_specification;
template <class T> class exception_specification<add3_function<T,T,T,T> >
{ // Here add3_function<> is a function object for add3
  typedef exception_specification<plus<T> >::spec spec;
};

template <class T> T add3(T a, T b, T c) 
throw (exception_specification<add3_function<T,T,T,T> >::spec)
{ return a + b + c; }

But this is very verbose, requires every user function to have a corresponding
exception specification specialization (in addition to a function object) 
and does get ugly when declaring multiple exception specifications for
a single function.
-- 
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads