C++ exception handling
Dan Moinescu
Are there any plans to change the C++ standard to
force exception specifications being checked at
compile-time (as Java does), rather than at run-time?
I recently had to change the exception specification
of a library function. Since this change is not
detected during compilation at all, I have to manually
check the code where that function is called in order
to accommodate the new exceptions. As you can imagine,
that’s a nightmare. In the Java exception model, any
exception thrown inside a function must be either
caught or declared in the function’s throw list
(that’s enforced during compilation). Had that been
the case with C++, a simple compilation of the
projects would have detected the all the places where
the new exceptions are thrown and not caught.
Also, I believe such a change would help improve the
quality of the C++ code that uses exceptions.
Currently, if an exception is omitted from a catch
block, no indication of that is given at compilation.
If you’re lucky, the bug is discovered during testing;
if not, it goes on undetected. And when the exception
does eventually occur, the application will not be
able to provide any indication of where exactly the
exception occurred.
Best regards,
Dan Moinescu.
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Carl Daniel
news:2002080214184...@web9902.mail.yahoo.com...
> Hello everyone,
>
> Are there any plans to change the C++ standard to
> force exception specifications being checked at
> compile-time (as Java does), rather than at run-time?
Quite the reverse, actually.
If there's any trend that's been discussed frequently in this forum, it's to
deprecate or eliminate exception specifications from the language, except
possibly the empty throw() specification.
This trend appears to stem from two facts:
1. Exception specifications are pessimizations in most real-world
implementations. That is, they _force_ the compiler to generate larger,
slower code.
2. Static checking of exception specifications a-la Java doesn't bring real
safety:
a. There are exceptions that are not checked (e.g. anything derived from
Error).
b. There are huge loopholes (e.g. a JNI method can raise _anything_
regardless of exception spec).
That siad, yes, the problems you describe are real - but don't expect to see
static exception checking in C++ showing up in your favorite compiler any
time soon, IMO.
-cd
Alexander Terekhov
Carl Daniel wrote:
[...]
> 1. Exception specifications are pessimizations in most real-world
> implementations. That is, they _force_ the compiler to generate larger,
> slower code.
Yeah, but the only reason for that is a rather silly {and currently
standard} "UwUUcU" requirement for mandatory Unwinding with Utterly
Ugly "catch(...)"->Unexpected() "handling"... instead of somewhat
more intelligent two phase [check/search-first-and-then-unwind-
if-expected] exception handling with unexpected() invoked at
throw point. IMHO.
regards,
alexander.
Carl Daniel
news:3D4C0CDA...@web.de...
>
> Carl Daniel wrote:
> [...]
> > 1. Exception specifications are pessimizations in most real-world
> > implementations. That is, they _force_ the compiler to generate larger,
> > slower code.
>
> Yeah, but the only reason for that is a rather silly {and currently
> standard} "UwUUcU" requirement for mandatory Unwinding with Utterly
> Ugly "catch(...)"->Unexpected() "handling"... instead of somewhat
> more intelligent two phase [check/search-first-and-then-unwind-
> if-expected] exception handling with unexpected() invoked at
> throw point. IMHO.
IMO, you're absolutely correct!
-cd
Daniel Miller
> In article <3D501B4D...@web.de>, Alexander Terekhov wrote:
>
>>>If we ditch the stupid runtime checks...
>>>
>>Do really think that runtime checks without unwinding would be
>>stupid?
>>
>>Why?
>>
>
> I shouldn't have said "Stupid", I don't believe they offer any
> benefit - or rather that they offer less benefit than an a purely
> comiple-time exception checking mechanism would, and have an
> unacceptable cost. The consensus seems to be that the exception
> specification mechanism we have in the language today isn't worth
> using (the advice from most C++ language authorities is to avoid
> ESs apart from empty ones)
>
> If checks were made at compile-time there should be no need to
> perform any additional checks at runtime. Runtime checks are bad
> because they have a cost in code size and in execution time,
> compile-time checks are good because they eliminate the need for
> runtime checks.
[...snip...]
> As I said in my previous post, I do appreciate that getting
> compile-time ES checking right isn't going to be easy. There are
> issues with templates, and with pointers to functions, and whether
> a function's ES should be part of it's type (I think yes, but that
> raises new issues). I think the first thing the community has to
> do is to accept that what we have today isn't really useful - and
> isn't being used, because of that - and to change it.
No, that is not the "first thing" that someone needs to do.
With your "first thing" you are assuming that "the community" is
open-mindedly liberal in their thinking, entertaining all new ideas no
matter how silly to see if there exists any 5% pearl of wisdom to
harvest out of the 95% dreck of the idea. Instead I consistently see
over & over that "the community" behaves largely in the opposite manner.
Even if an idea is 95% perfect, "the community" will tear the idea to
shreds, focusing on the 5% of tarnish, and then dismiss the entire idea
in order to preserve the status quo (instead of polishing off the 5% of
tarnish or mounting the missing crowning jewel). And maybe this defense
of the status quo is natural human behavior when pride-of-authorship
(e.g., of C++98) is involved or when they themselves have not yet
invented a solution to the problem.
Given this frequently-exhibited proclivity toward treating all new
ideas as deserving of attack as a mechanism of enforcing the status quo,
don't play into that game, due to its squelching effect. Instead let us
focus *not* on
1) changing people's minds,
2) then reaching consensus, and then
3) then taking action together as a united happy agreeing front,
but rather on the opposite order:
1) take action yourself (and any few direct allies with whom you
share common viewpoints) where this action is building a working
demonstration. But make sure during this phase that you push for
something extremely worthwhile for the future of humankind with very few
(or no) warts because this is the phase of free thinking,
open-mindedness, friendship, invention, discovery, and excitement. If
you don't get it right during this phase, the idea will forever be
crippled, as the cement sets in the next phases.
2) then build consensus by making it part of the public distribution
of one or more compilers. This naturally involves freezing the idea to
some degree so that churn is minimized as it is publicly rolled out in
this wide distribution.
3) then let the good experience gained by the
ever-more-widely-distributed publicly-released products change people's
minds, and
4) then standardization submissively complies with widely-established
existing practice, at most tinkering around the fringes---as it should
be. During this phase, adjust the documentation from prior phases so
that it conforms to the standard-body's own variation of standards-speak.
Specifically regarding compile-time enforcement of
exception-specifications, devise a solution to those big problems
yourself (or among your friends). Write it up as formally & lucidly &
completely as possible, such as John Nagle's
http://www.animats.com/papers/languages/index.html (or in a different
era, such as Musser & Stepanov's Ada generics library and precursors of
STL which attracted Stroustrup's interest). Modify a compiler for which
you have source code. Preferably modify an open-source compiler which
is willing to consider contributions from outside their regular
developers (unless you are one of those regular developers). Currently
this set of open-source C++ compilers willing to entertain extensions
might include GNU C++, but in the future might include OpenWatcom as
well. Design your extension not as a hack which barely works in a few
rigged-up cases, but rather as production-quality which can be turned on
via a command-line option (where the extension is off by default). Try
out the extension extensively. Learn about it among your friends &
colleagues. Improve the idea before throwing the idea out to "the
community" meat-grinder. Negotiate to get the extension placed into the
production compiler product to ship at next release (so that we all may
try out the extension). Continue evolving that write-up to mesh well
with the standardese language of ISO/IEC 14882. Negotiate with other
compiler vendors over time to add the extension, as we see with compiler
vendors implementing Microsoft & GNU extensions prior to standardization.
Don't get me wrong, though. The meat-grinder of seemingly limitless
negativity in "the community" is very useful criticism, especially when
observing the meat-grinder shred someone else's ideas which are vaguely
similar to your own, allowing you to hone in on what went wrong in the
other person's ideas and to adjust your ideas in private to no longer be
susceptible to that criticism. Harvest the pearls of wisdom which come
your way via that process (and throw away the dreck).
It is my hope that no rational human being in the C++ community is
permanently fervently against *all* future *perfect-without-flaw*
variations of exception-specifications, but rather today there are
numerous people who are against exception-specifications as
exception-specifications currently stand due to the
not-yet-completely-thought-out topics. If you or others truly solve the
various template problems, pointer-to-function problems, and
span-compilation-unit problems (the easiest of the three IMO) and then
follow the plan laid out above, as a matter of course minds will in fact
change and the feature would eventually be accepted (and maybe even
celebrated as a major achievement). The worst that happens by trying to
solve those big problems with exception-specifications is that you
discover (and preferably formally prove) why they cannot be solved,
which is its own kind of advance of humankind to no longer lament lack
of progress on that topic anymore.
By the way, I fully agree with every bit of your advocacy of
exception-specifications. If there exists a reason why I myself don't
take up the challenge regarding exception-specifications, it is that I
have been focusing on other hard topics in C++.
Go forth and prosper. :-)
Sergey P. Derevyago
> You missed the point that C++ has templates and the exception specification
> of a template function might vary with the types with which it is
> instantiated.
> No-one has managed to present a plausible syntax for expressing that.
I think I did (Message-ID: <3A5887F9...@iobox.com>):
-----------------------------------8<-----------------------------------
1.
// f can throw what it wants
void f()
{
// ...
}
2.
// f is not allowed to throw (checked at compile time)
void f() nothrow
{
// ...
}
3.
void f()
{
// ...
nothrow { // you can't throw in this scope (checked at compile time)
// ...
}
// ...
}
-----------------------------------8<-----------------------------------
For example, here is an exception safe generic assign:
template <class T, class U>
T& assign(T& t, const U& u)
{
T tmp(u);
nothrow { swap(t, t2); }
return t;
}
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
Allan W
> With your "first thing" you are assuming that "the community" is
> open-mindedly liberal in their thinking, entertaining all new ideas no
> matter how silly to see if there exists any 5% pearl of wisdom to
> harvest out of the 95% dreck of the idea. Instead I consistently see
> over & over that "the community" behaves largely in the opposite manner.
> Even if an idea is 95% perfect, "the community" will tear the idea to
> shreds, focusing on the 5% of tarnish, and then dismiss the entire idea
> in order to preserve the status quo (instead of polishing off the 5% of
> tarnish or mounting the missing crowning jewel). And maybe this defense
> of the status quo is natural human behavior when pride-of-authorship
> (e.g., of C++98) is involved or when they themselves have not yet
> invented a solution to the problem.
I don't think that's quite fair.
Surely for any idea presented, there will be at least a few people that
hate any kind of change, and a few others that would be gung-ho for it.
But on the whole, I think that most people appreciate improvements in
the language if they follow certain basic principles:
1. Make sure that it's genuinely useful. You might think that the
Java keyword "implements" is a cool idea, but none of us are
forcing you to use C++ instead of Java. If you really think that the
C++ language ought to have this keyword too, you're going to have to
tell us why WE need it.
2. Minimize the amount of existing code that breaks. This does not mean
that there will never be any changes that break any existing code;
it just means that the more code you break, the more strongly you're
going to have to show the advantages.
Note that almost any new keyword has the potential to break some
program that used it as a variable name, so this type of proposal
is always going to generate some negativity.
3. Stay true to C++. By that, I mean the opposite of what most people
seem to mean when they use the phrase! To me, one of the most
important features of C++ is that it supports many DIFFERENT ways
of writing code. For instance, C++ will always support the use of
classes (making it an object-oriented language); and yet, you can
write major systems without any user-defined classes at all.
So if your suggestion is, "remove some programming construct that
nobody uses anyway," you're going to really have to prove that
nobody uses it anyway (or make an even stronger case why nobody
ever should have, and also explain why it's okay to break the code
of everyone that did use it).
4. Make sure that it can be done, and that the run-time penalties are
low (especially for code that does NOT use the new feature). If
you're just not sure, say so -- people will be more than willing
to tell you!
5. Don't assume that your way is the only way to do it. When you figure
out a way to solve a problem, say so -- but be sure to tell us what
problem you're solving, too. Once you get people thinking about the
problem, then "the community" might come up with an even more elegant
way to solve the same problem.
6. Don't take it personally. Bjarne Stroustrup himself had a lot of
ideas rejected -- and he's the inventor of the language! Just because
you think that some idea is the best thing since encapsulation,
doesn't mean that everyone else is going to want the change. If you
use this as proof that "the community" consists only of egotists (or
racists, or religious bigots, or that they always support each other
at your expense) then you can perhaps cause a low-temperature flame
war (*), but the only thing this will really serve is your own sense
of indignation. On the other hand, if you make a good suggestion and
respond meaningfully to questions about it, then there's a good
chance that there will at least be reasonable discussion about it.
(*) The moderation policy of course prohibits explicit flames. But
"holy wars" are common!
> The problem is, AAA causes problems BBB and CCC and DDD, but
I never said AAA! What I said was, EEE -- which is a completely
different thing!
> and of course FFF
Like I said six weeks ago, FFF can be solved by only using AAA
when GGG is in the room! Or are you deliberately ignoring me?
You think I'm making this up? Or talking about some specific, recent
thread? Look for any thread with 200 or more messages; or look for
any thread with at least two messages that say,
> > But when you said AAA was
> I never said AAA!
Yes you did, on October 1. Here's the full quote:
...and so on. Once you reached the stage where two or more people start
telling each other what they said, there's no longer any chance that
they will reach any sort of concensus. Instead, it's become a holy war,
similar in many ways to a thread such as "Why Java is better than C++"
(or vice-versa!). Sometimes these things simply fade away; other times
they end with an angry sign-off, but NEVER a concensus.
Ken Hagan
> > You missed the point that C++ has templates and the exception
specification
> > of a template function might vary with the types with which it is
> > instantiated.
> > No-one has managed to present a plausible syntax for expressing that.
"Sergey P. Derevyago" <non-ex...@iobox.com> wrote...
>
> I think I did (Message-ID: <3A5887F9...@iobox.com>):
Sorry, but that's not even close, in my opinion. Consider a function that
catches
one class of exception and throws another. (Perhaps this "translation" is
sole the
purpose of the function, perhaps not.)
template<class T> void T::Operate()
{
try { /*do stuff*/ }
catch (std::bad_alloc e) { throw T::NoDiscSpace; }
}
I need to be able to write the ES for T::Operate. Assume that /*do stuff*/
does
things that depend on the template parameter. If it throws nothing, then
Operate
throws nothing. That's clearly an important property that we would want to
express
statically. If it throws just std::bad_alloc or T::NoDiscSpace, then Operate
throws
only the latter, and a caller who catches that has an empty ES itself.
That's also
an important property that we'd like to be able to deduce. If it throws
anything else,
they will propogate unchanged.
So, I need to be able to write an ES that depends on the ES-es of other
functions,
where those other functions may depend on template parameters.
The consensus to date has been that such a detailed analysis requires too
much
ugly supporting syntax for the benefit obtained. Yes we'd like to be able to
prove
that exceptions never propogate out of some functions (not least because
some
environments just don't tolerate it at all) but if it is going to force us
to write ugly
exception specifications and in particular if it is going to increase the
fequency with
which we have to change declarations in header files, then we aren't
interested.
For a reasonably large subset of programs, whole-program analysis (at
link-time
rather than compile-time) could generate the exception specifications
automatically.
This avoids the template problem, because everything is done
"post-instantiation"
so the exact types are known. (If we didn't have export, then we could use
this
approach at compile-time.)
However, I'm not aware of anyone doing this, and it runs into problems
(probably
not insurmountable) with libraries for which source code is not available
and it may
also run into (harder) problems with recursive calls. Finally, unless the
analysis is
truly exhaustive it probably still generates false positives when fed code
like...
T sqrt(T t) { if (t<0) throw std::logic_error; else return t.sqrt(); }
...
T r = sqrt(+6); // can't throw
(This case is easy, but proving that sqrt's argument is non-negative is
generally a hard
problem.)
Sergey P. Derevyago
> > I think I did (Message-ID: <3A5887F9...@iobox.com>):
> Sorry, but that's not even close, in my opinion.
1. I want to write exception safe code, so (statically checked) nothrow is the
solution, IMHO.
2. While you want to futher extend those bra^H^H^H dead-born exception
specifications :)
> template<class T> void T::Operate()
> {
> try { /*do stuff*/ }
> catch (std::bad_alloc e) { throw T::NoDiscSpace; }
> }
>
> I need to be able to write the ES for T::Operate. Assume that /*do stuff*/
> does things that depend on the template parameter. If it throws nothing,
> then Operate throws nothing.
Well. I also propose the overloading based on nothrow:
template <class T /* ... */>
class A {
// ...
A& operator=(const A& a)
{
A tmp(a);
swap(tmp);
return *this;
}
A& operator=(const A& a) nothrow
{
// do something else
return *this;
}
};
> T sqrt(T t) { if (t<0) throw std::logic_error; else return t.sqrt(); }
> ...
> T r = sqrt(+6); // can't throw
>
> (This case is easy, but proving that sqrt's argument is non-negative is
> generally a hard problem.)
Imagine: there is no spoo^H^H^Hilver bullet. In those rare cases where we
know that something() doesn't really throw we can/must use empty try/catch
blocks:
try { something(); }
catch(...) {} // ignore
This code is easy to understand and it's quite efficient (the overhead of EH
can be drawn below 5%. Hi, Dave! ;).
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
Alexander Terekhov
"Sergey P. Derevyago" wrote:
[...]
> > T sqrt(T t) { if (t<0) throw std::logic_error; else return t.sqrt(); }
Hello my lovely std::logic_error! ;-)
> > ...
> > T r = sqrt(+6); // can't throw
> >
> > (This case is easy, but proving that sqrt's argument is non-negative is
> > generally a hard problem.)
> Imagine: there is no spoo^H^H^Hilver bullet. In those rare cases where we
> know that something() doesn't really throw we can/must use empty try/catch
> blocks:
>
> try { something(); }
> catch(...) {} // ignore
Now image that something() would throw STACK OVERFLOW, or something
like that. Do you REALLY want "catch(...) {} // ignore" it?!
http://groups.google.com/groups?selm=3D6275AE.78E6DF99%40web.de
("Subject: Re: extern "C" and exception handling....", c.l.c++)
"....
http://www.testdrive.compaq.com
http://tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_PDF/ARH9RBTE.PDF
----
spe207.testdrive.compaq.com> what /shlib/libpthread.so|grep DECthreads
DECthreads version V3.18-138 May 12 2002
spe207.testdrive.compaq.com> cc -pthread -o seh seh.c
spe207.testdrive.compaq.com> ./seh
Go...
Hi There! Greetings from the ``yellow zone.''
Exception: Attempted stack overflow was detected (dce / thd)
Indeed. ;-)
spe207.testdrive.compaq.com> cat seh.c
#include <stdio.h>
#include <memory.h>
#include <pthread.h>
#include <pthread_exception.h>
void operation()
{
char buffer[128];
memset( buffer, 0, sizeof( buffer ) );
operation();
}
void* my_thread( void* p )
{
TRY {
printf( "\nGo...\n\n" );
operation();
}
CATCH_ALL {
printf( "Hi There! Greetings from the ``yellow zone.''\n\n" );
pthread_exc_report_np( THIS_CATCH );
TRY {
RERAISE;
}
CATCH( pthread_stackovf_e ) {
printf( "\nIndeed. ;-)\n\n" );
} ENDTRY
}
ENDTRY
return NULL;
}
int main()
{
pthread_t tid;
pthread_create( &tid, NULL, &my_thread, NULL );
pthread_exit( NULL );
}
spe207.testdrive.compaq.com> cc -pthread -c -o seh2c.o seh2c.c
spe207.testdrive.compaq.com> cxx -pthread -o seh2 seh2cpp.cpp seh2c.o
spe207.testdrive.compaq.com> ./seh2
C++ try...
Go...
Hi There! Greetings from the ``yellow zone.''
Exception: Attempted stack overflow was detected (dce / thd)
Indeed. ;-) Ha! >>RERAISE<<
C++ catch(...)
Finished!
spe207.testdrive.compaq.com> cat seh2c.c
#include <stdio.h>
#include <memory.h>
#include <pthread.h>
#include <pthread_exception.h>
void operation()
{
char buffer[128];
memset( buffer, 0, sizeof( buffer ) );
operation();
}
void go()
{
TRY {
printf( "\nGo...\n\n" );
operation();
}
CATCH_ALL {
printf( "Hi There! Greetings from the ``yellow zone.''\n\n" );
pthread_exc_report_np( THIS_CATCH );
TRY {
RERAISE;
}
CATCH( pthread_stackovf_e ) {
printf( "\nIndeed. ;-) Ha! >>RERAISE<<\n\n" );
RERAISE;
} ENDTRY
} ENDTRY
}
spe207.testdrive.compaq.com> cat seh2cpp.cpp
#include <pthread.h>
#include <iostream>
using namespace std;
extern "C" void go();
extern "C" void* my_thread( void* p )
{
cout << "\nC++ try..." << endl;
try {
go();
}
catch(...) {
cout << "C++ catch(...)" << endl;
}
cout << "\nFinished!\n" << endl;
return 0;
}
int main()
{
pthread_t tid;
pthread_create( &tid, 0, &my_thread, 0 );
pthread_exit( 0 );
}
...."
< Forward Inline >
-------- Original Message --------
Message-ID: <3D6507EB...@web.de>
Date: Thu, 22 Aug 2002 17:48:59 +0200
From: Alexander Terekhov <tere...@web.de>
Newsgroups: comp.lang.c++.moderated
Subject: Re: A better C++ finite state machine framework
"Sergey P. Derevyago" wrote:
>
> David Abrahams wrote:
> > Maybe. Once a "return" statement is executed the programmer is usually not
> > so explicitly aware of the destructors that execute on the way out of the
> > function. Nor is she commonly explicitly aware of all destructors that
> > execute when "falling off the end" of a void-returning function... and these
> > are precisely the same paths that execute when an exception is thrown. No
> > more, no less.
>
> Sorry, Dave, but you've again made an inaccurate statement: destructors are
> allowed to throw during return, ....
Unless they have "throw()"-nothing exception specifications (ES):
http://lists.boost.org/MailArchives/boost/msg34061.php
(Subject: [boost] Re: Attempting resolution of Threads & Exceptions Issue)
and, never mind that the way how ES are specified in the current
C++ language is, well, IMNSHO somewhat "flawed":
http://lists.boost.org/MailArchives/boost/msg34239.php
(Subject: [boost] Re: Attempting resolution of Threads & Exceptions Issue)
regards,
alexander.
Ken Hagan
> 1. I want to write exception safe code, so (statically checked) nothrow is
the
> solution, IMHO.
> 2. While you want to futher extend those bra^H^H^H dead-born exception
> specifications :)
Actually my interest also lies with 1 rather than 2. It's just that I can't
see
how to achieve one without the other. I'm not prepared to declare all my
template functions as throw(...), throw(), throw(std::exception) of anything
else, because any particular ES will stop me using the template with certain
types, at least usefully. Let me break down my chain of thought here.
1 I'm only interested in checking "nothrow" at a few places in my code.
2 The appropriate ES of other functions is just "whatever they can throw".
3 That depends on what they call.
4 For non-templates, "what they call" was fixed at compile-time, so the
original ES proposal was workable.
5 For template functions it isn't fixed until instantiations are made; To
check
at compile-time, the ES would need to be a formula for "how to compute
the actual ES for given template parameters".
That's why I gave the impression of wanting to extend ES. In fact, I don't.
I'd
much prefer either of the following.
[A] Force whatever tool does template instantiation, to generate an "actual
ES"
independently of what's in the source code. That can then be checked
by
for the entire program in one go.
[B] Decide that the above is too much of a requirement for compiler
vendors,
but suitable for external tools like lint.
In either case, the programmer would only need to write an ES where they
wanted an actual check, and check failures would not prevent the build from
being successful.
With this kind of checking available, I can't see any need for the current
run-time
semantics, so I'd be inclined to ban^H^H^H deprecate them.
Alexander Terekhov
Ken Hagan wrote:
[...]
> With this kind of checking available, I can't see any need for the current
> run-time semantics, so I'd be inclined to ban^H^H^H deprecate them.
The need for run-time semantics is rather simple: any UNEXPECTED throw
should end up {ideally at throw point} in unexpected() "handler"; NOT
in some silly try {/**/}catch(/**/) { /*EMPTY: ignore*/ } handler.
http://lists.boost.org/MailArchives/boost/msg34251.php
(Subject: [boost] Re: Attempting resolution of Threads & Exceptions Issue)
<quote>
> > > You can put an exception specification that prohibits std::logic_error
> > > on the threadproc (and hope that it doesn't unwind ;-) .)
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Peter, I'm going to IGNORE your wink. ;-) That's rather serious
> > issue/design flaw in the current C++ language, I believe strongly.
>
> It is, if you insist that throwing an exception is the right thing to do
> when you detect a programming error.
>
> It's not, if you don't.
Yeah, the only problem is that it's not "that simple", I'm afraid.
(imagine that some find()-like function using something like get()
below in some similar way... WOULD cause get() to "unexpectedly"
throw -- due to something silly done prior to calling get() inside
the if/loop (after size() check) or something else... perhaps another
thread corrupting shared data, whatever... Y'know: errors that "can't
happen" and that manifest themselves via unexpected throws; and NOT
necessarily throwing std::logic_error-like things or generating
SEH/"hardware exceptions").
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.rtf
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
(Guidelines for Using Exception Specfications, Jack Reeves)
<quote>
Consider the following example (only slightly contrived).
X get(int i) throw(out_of_range);
int find(X& x) throw()
{
for (int i = 0; i < size(); ++i) {
if (x == get(i)) return i;
}
return -1;
}
Here, function find() calls a function, get(), which states that it
can throw an exception. Function find() however, has an exception
specification that states that it will not throw any exceptions. If
exception specifications were checked a compile time, then function
find() would generate an error message on the line that calls get().
Nevertheless, this programmer has carefully written find() to include
a test (i < size()) that will avoid the condition which would cause
get() to throw an exception. In C++ (as in C) the assumption is that
the programmer knows what he is doing. C++ programmers expect this
to compile without even a warning. Certainly, I would not want to
write code like this int find(X& x) throw()
try {
for (int i = 0; i < size(); ++i) {
if (x == get(i)) return i;
}
return -1;
}
catch (out_of_range) {
return -1;
}
</quote>
<snip>
http://groups.google.com/groups?selm=c29b5e33.0202110310.413c19cb%40posting.google.com
("Subject: Re: Java-like exception specifications", #pragma unexpected_exception)
</quote>
regards,
alexander.
apm
> Ken Hagan wrote:
> > > I think I did (Message-ID: <3A5887F9...@iobox.com>):
> > Sorry, but that's not even close, in my opinion.
> Yes. It seems like we have different goals:
> 1. I want to write exception safe code, so (statically checked) nothrow is the
> solution, IMHO.
because of the difficulties with templates. The discussion document,
which includes points raised in USENET dscussions, can be found at
http://wwww.andrewmarlow.co.uk/publications.html
-Andrew M.
Sergey P. Derevyago
> > try { something(); }
> > catch(...) {} // ignore
>
> Now image that something() would throw STACK OVERFLOW, or something
> like that. Do you REALLY want "catch(...) {} // ignore" it?!
and must be separated. IMHO robust code will cope with OS "exceptions" by
means of system-dependent APIs anyway to get the _full_ control.
While one may think that the mixture of C++ and OS exceptions might help to
write toy programs I think that it's an explosive mixture for any serious
project.