It's another legacy issue.  Exceptions went into the core
language before class "Exception" did.  If all exceptions in
standard libraries derived from class "Exception", and most
user defined exceptions derived from class "Exception", then
compile-time checking of exception specifications would have
worked out.  Almost all functions would indicate that they
threw "Exception".

   John Nagle
   Animats

Frank Pilhofer wrote:

> Alexander Terekhov <terekhov@web.de> wrote:
>
>> http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.rtf
>> http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
>>
>
>
>  Good article. Another point in case might be the iostream library, where
> I/O may or may not throw basic_ios::failure, based on a run-time setting.
>
>  Still, I wonder if exception-safety could be "hardened" without placing
> too much burden on developers having to catch exceptions that they know
> will not occur.
>
>  One suggestion might be to extend function definitions to include
> "unexpected" exceptions, i.e. exceptions that might be thrown according
> to the set of all callee's exception specifications, but that are not
> expected. In the given example, that might be
>
>  int find (X& x) throw() unexpected_(out_of_range) { /* ... */ }
>
>  A compiler would do the same as before, i.e. call unexpected() whenever
> an unexpected exception occurs. But compilers could then better check
> for non-allowed exceptions: the set of allowed plus unexpected exceptions
> would have to be larger or equal to the sum of "potential" exceptions.
>
>  But maybe such a change, combined with the additional burden on the
> developer, is too much of a tradeoff for the added benefit.
>
>  Frank
>
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>    It's another legacy issue.  Exceptions went into the core
> language before class "Exception" did.  If all exceptions in
> standard libraries derived from class "Exception", and most
> user defined exceptions derived from class "Exception", then
> compile-time checking of exception specifications would have
> worked out.  Almost all functions would indicate that they
> threw "Exception".
>
> John Nagle
> Animats
>

This is exactly the proposition I recently made elsewhere. I would like to
know if others find logical fault in the argument that requiring all
exceptions to derive from a common baseclass would enable compile-time
exception specification checking.

If the proposition is sound, then how desireable would it be to have such
support?  How could the legacy issues be mitigated? Is a transition to the
proposed requirement feesable?

My inclination is to propose some means of wrapping legacy calls in a
catchall block and wrap any exception that occurs in a generic
legacy_exception object which extends std::exception

--
STH

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

susudata@setidava.kushan.aa ("Steven T. Hatton") wrote in message news:<-aqdnV_pe-zXffzdRVn-ug@speakeasy.net>...
>
> This is exactly the proposition I recently made elsewhere. I would like to
> know if others find logical fault in the argument that requiring all
> exceptions to derive from a common baseclass would enable compile-time
> exception specification checking.

Logical fault #1:

A common base class isn't necessary nor sufficient to enable compile
time checking of exception specifications.  (It is possible provided
the exception mentioned are of complete types at the point of
checking.)

Logical fault #2:

There is a lot of perfectly unbroken C++ code that would not pass such
a check.

> If the proposition is sound, then how desireable would it be to have such
> support?

Not very.  Referring back to the OP: C++ exceptions are much closer to
Java's RuntimeExceptions than to Exceptions.

It is worth noting that Java has both checked and unchecked exceptions
and uses both.  Also of relevance is that C# (which has applied
lessons learnt from experience with Java) reverts to the C++ (et alia)
approach of unchecked exceptions.

> How could the legacy issues be mitigated? Is a transition to the
> proposed requirement feesable?
>
> My inclination is to propose some means of wrapping legacy calls in a
> catchall block and wrap any exception that occurs in a generic
> legacy_exception object which extends std::exception

My inclination would be to allow a new checked exception mechanism
rather than changing the old one.  Perhaps to require compile time
checks for exceptions derived from "std::checked_exception"?

BTW

I think both checked and unchecked mechanisms have value:

    http://www.octopull.demon.co.uk/sw-dev/IfProblemsArise.html
--
Alan Griffiths <alan@octopull.demon.co.uk>
http://www.octopull.demon.co.uk/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

   Hi,

 From my limited experience of programming in Java, I fondly remember
that the Java compiler complained when a potential non-allowed exception
was not properly handled. It is a PITA to declare and handle exceptions
consistently, but I figured that it is ultimately worth it.

 Now ISO C++ says in 15.4, paragraph 10, that

    An implementation shall not reject any expression merely because
    when executed it throws or might throw an exception that the
    containing function does not allow. [Example:

    extern void f() throw (X, Y);
    void g() throw (X) { f(); }

    the call to f is well-formed even though when called, f might
    throw exception Y that g does not allow. ]

 What is the rationale for that?

 Wouldn't it be helpful if a compiler emitted at least a diagnostic?
Maybe there are such compilers -- but at least gcc doesn't.

 Frank


--
Frank Pilhofer  ...........................................  fp@fpx.de
Adolescence is that period in a child's life when parents become
most difficult! - Alfred E. Neuman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Frank Pilhofer wrote:
[...]
>     extern void f() throw (X, Y);
>     void g() throw (X) { f(); }
>
>     the call to f is well-formed even though when called, f might
>     throw exception Y that g does not allow. ]
>
>  What is the rationale for that?

This might help:

http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.rtf
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm

regards,
alexander.

--
http://groups.google.com/groups?selm=3D661874.F3A00006%40web.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alexander Terekhov <terekhov@web.de> wrote:
>
>  http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.rtf
>  http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
>

 Good article. Another point in case might be the iostream library, where
I/O may or may not throw basic_ios::failure, based on a run-time setting.

 Still, I wonder if exception-safety could be "hardened" without placing
too much burden on developers having to catch exceptions that they know
will not occur.

 One suggestion might be to extend function definitions to include
"unexpected" exceptions, i.e. exceptions that might be thrown according
to the set of all callee's exception specifications, but that are not
expected. In the given example, that might be

 int find (X& x) throw() unexpected_(out_of_range) { /* ... */ }

 A compiler would do the same as before, i.e. call unexpected() whenever
an unexpected exception occurs. But compilers could then better check
for non-allowed exceptions: the set of allowed plus unexpected exceptions
would have to be larger or equal to the sum of "potential" exceptions.

 But maybe such a change, combined with the additional burden on the
developer, is too much of a tradeoff for the added benefit.

 Frank


--
Frank Pilhofer  ...........................................  fp@fpx.de
It's what you learn after you know it all that really counts.
- Alfred E. Neuman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Frank Pilhofer wrote:
>
> Alexander Terekhov <terekhov@web.de> wrote:
> >
> >  http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.rtf
> >  http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
> >
>
>  Good article. Another point in case might be the iostream library, where
> I/O may or may not throw basic_ios::failure, based on a run-time setting.
>
 IMHO the following URLs are also worth to look at:
1. Introduction of the nothrow keyword:
http://groups.google.com/groups?selm=3A5887F9.6CFCFFD7%40iobox.com&oe=UTF-8
2. Specialization on nothrow (unfortunately, I used word "overloading" instead
of "specialization")
http://groups.google.com/groups?selm=3C4BE54C.15939697%40iobox.com&oe=UTF-8
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>  Still, I wonder if exception-safety could be "hardened" without placing
> too much burden on developers having to catch exceptions that they know
> will not occur.

When I'm dealing with libraries, I usually want to know what exceptions
can occur, or even whether exceptions can occur.  I think it would be
great to have reliable exception specifications on third party library
header files so I could plan my client code accordingly.  I've mulled
over this problem quite a bit and unfortunately I can't come up with a
solution that allows people who want to ignore exceptions (beyond making
things exception safe) to not have to specify the throw clause.  I can
think up things that are pretty close to what I would like, but they end
up requiring some sort of global analysis phase which isn't very
friendly to a separate compilation model.  Of course, the issue is
compounded by templates and polymorphism (though in different ways, IME).

I find that things aren't helped much by simplifying the problem to only
deal with the empty throw() clause.  I find that maybe 80% of the time
this would give me what I want, but I can't see a framework that allows
the compiler to verify that the throw() is correct unless the exceptions
that are thrown by called functions can be deduced, which then requires
solving the general problem over again.

On the other hand, I find that even knowing what exceptions "could" be
thrown from which functions ends up giving me less than 100% of what I
would want anyway, because what I sometimes _really_ want is to know
under what circumstances the exception is possible.  Some exceptions
can't be prevented within the program (such as I/O oriented exceptions
for example), but some can be (I know certain I/O failures won't happen
when the argument is an istringstream, for example) and it's
unreasonable to expect even a global analysis phase to have the
intelligent deduction capabilities to figure all of that, certainly
within a normal build cycle.

This then forces me to confess that what I really require is good
documentation of the interfaces I'm forced to deal with.  Unfortunately,
I find that:
1) Documentation can't be verified by the compiler.
2) Possible exceptions, in my experience, are one of the pieces of
documentation that is most likely to be missing, incomplete, or
incorrect, or to give little or no detailed information.
3) I work in research and frequently deal with libraries where the code
is incomplete or in flux, and the documentation is an afterthought if at
all.  Fortunately I usually have access to the authors (sometimes I am
the author), but they can't provide information that would be as useful
as a correct exception specification would be if we could even pull it
off at the language level.

So, this forces me to confront the reality that I live in a very
imperfect world, and I just have to deal with it.  Oh, well.

While I'm talking, though, I'd like to mention that I disagree with one
of the article's finer points.  I usually prefer that destructors throw
no exceptions, even if they are polymorphic, and I don't see a critical
failing to giving them an empty throw() clause.  IMHO, a destructor that
throws an exception is unexpected() waiting to be called, and I'd rather
have it called sooner than later.  But I'm sure there are people who
disagree with me, and I wouldn't be surprised if they have pretty good
reasons too.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]