A few exception questions
Marijn
When you throw exceptions from a function you specify 'throw
(Exceptionclassname)' in its declaration. However, if you throw
exceptions and omit this the compiler does not mind at all. How exactly
will this behave at runtime? Will the thrown exception immediately be
seen as uncaught, terminating the application? Same when calling
functions that throw from functions that do not throw without using a
try block.
In another thread Bruno Ritz asks if there is a way to force users of
functions to catch the stuff it throws. This was not the case. I was
wondering if there is a compiler flag that can be set to at least
generate warnings about uncaught exceptions. I'm often routing function
calls all over the place and tend to forget to include a 'throw'
specification in one of the functions i pass through, thus making my
try/catch blocks useless because the exceptions cause a terminate in
some intermediary function.
Marijn
Peter van Merkerk
news:3F2795E9...@hotmailDOT.com...
> Hello.
>
> When you throw exceptions from a function you specify 'throw
> (Exceptionclassname)' in its declaration.
You may do that, but you don't have to. If you don't specify which
exceptions a function may throw, as far as C++ is concerned, it may
(directly or indeirectly) throw any exception. However if you specify
which exceptions a function may throw, you essentially say this function
promisses to only throw the specified exception(s). Unfortunately the
exception specification is not enforced at compile-time. Many people
consider the exception specification mechanism in C++ to be broken, and
avoid exception specifications altogether:
http://www.gotw.ca/publications/mill22.htm
http://www.boost.org/more/lib_guide.htm#Exception-specification
http://www.gotw.ca/gotw/082.htm
> However, if you throw
> exceptions and omit this the compiler does not mind at all. How
exactly
> will this behave at runtime? Will the thrown exception immediately be
> seen as uncaught, terminating the application?
The exception specification says nothing about which exception will be
caught, it only specifies which exceptions may be thrown by a function.
If that function violates its exception specification, at runtime the
unexpected() function will be invoked. Functions without an exception
specification may throw any exception they like, and therefore won't
risk calling the unexpected() function
> Same when calling
> functions that throw from functions that do not throw without using a
> try block.
Uncaught exceptions may terminate the application.
> In another thread Bruno Ritz asks if there is a way to force users of
> functions to catch the stuff it throws. This was not the case. I was
> wondering if there is a compiler flag that can be set to at least
> generate warnings about uncaught exceptions.
Compiler flags are implementation specific, you will have to consult the
documentation of your compiler. I don't think it likely that your
compiler has such a flag though.
> I'm often routing function
> calls all over the place and tend to forget to include a 'throw'
> specification in one of the functions i pass through, thus making my
> try/catch blocks useless because the exceptions cause a terminate in
> some intermediary function.
No that its not the case, a missing 'throw' specification does not mean
that exceptions won't be propagated to the calling function. Example:
#include <iostream>
void f1()
{
throw "Exception!";
}
void f2()
{
f1();
}
int main()
{
try
{
f2();
}
catch(const char* ex)
{
std::cout << ex << std::endl;
}
return 0;
}
The exception thrown in f1() will be catched in the main() function,
even though neither f1() no f2() have a exception specification.
You seem to have several misconceptions about exceptions and exception
specifications. I recommend you read a good book about it to learn what
exceptions do and what exception specifications mean in C++. Usenet is
not really the ideal medium to explain these things well.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Marijn
> that exceptions won't be propagated to the calling function.
I see. I had concluded this happened based on behaviour i saw in a program i
made (terminated instead of following the path i put in the catch block),
when i added the throws it seemed to work again. I must have done something
else wrong then though, i'll look into it again. Good thing i won't need to
specify throws, i was getting really annoyed by doing that all the time.
Thanks for the reply!
Marijn
Alexander Terekhov
Peter van Merkerk wrote:
[...]
> promisses to only throw the specified exception(s). Unfortunately the
> exception specification is not enforced at compile-time.
You simply don't get it, Peter. Warnings for uncaught exceptions might
indeed be helpful, but that shall not "outlaw" unexpected exceptions...
hence "#pragma unexpected_exception" (go do a search, my friend).
> Many people
> consider the exception specification mechanism in C++ to be broken, and
> avoid exception specifications altogether:
> http://www.gotw.ca/publications/mill22.htm
http://groups.google.com/groups?selm=3D3C0BCA.A5E2F8B2%40web.de
(Newsgroups: comp.lang.c++.moderated)
> http://www.boost.org/more/lib_guide.htm#Exception-specification
http://article.gmane.org/gmane.comp.lib.boost.devel/20800
(Exception handling... it's time to fix the
http://www.boost.org/more/error_handling.html)
> http://www.gotw.ca/gotw/082.htm
http://groups.google.com/groups?selm=3C77AFCB.481D2587%40web.de
(Subject: Re: Guru of the Week #82: Solution)
regards,
alexander.
P.S. http://groups.google.com/groups?selm=3ECBF373.B9EF5B69%40web.de
Peter van Merkerk
news:3F27AEDD...@web.de...
>
> Peter van Merkerk wrote:
> [...]
> > promisses to only throw the specified exception(s). Unfortunately
the
> > exception specification is not enforced at compile-time.
>
> You simply don't get it, Peter. Warnings for uncaught exceptions might
> indeed be helpful, but that shall not "outlaw" unexpected
exceptions...
> hence "#pragma unexpected_exception" (go do a search, my friend).
Any resonably competent C++ programmer knows that the behaviour of
#pragma is compiler specific. You don't have to take my word for it
(which I'm sure you don't), just look it up in ISO/IEC 14882.
(btw. I'm not your friend, nor do I have the ambition or desire to
become one)
> > Many people
> > consider the exception specification mechanism in C++ to be broken,
and
> > avoid exception specifications altogether:
> > http://www.gotw.ca/publications/mill22.htm
>
> http://groups.google.com/groups?selm=3D3C0BCA.A5E2F8B2%40web.de
I don't have time to follow links to your own postings, which usually
explain nothing but just reiterate your opinions with statements like
"braindead" without further explanation. I'm sure that I have
misconceptions about a great many things and that I have still plenty to
learn. But if I have to choose between a well motivated advice from
respected authorities in this area (like Herb Sutter, Scott Meyers and
people from the boost community just to name a few) or ramblings of a
usenet equivalent of the village idiot, I don't think the choice is that
hard.
With kindest regards,
Peter
Alexander Terekhov
Peter van Merkerk wrote:
[...]
> #pragma is compiler specific. You don't have to take my word for it
Any "reasonably competent" *C*/C++ programer knows that you're totally
confused here as well.
http://groups.google.com/groups?selm=3DDD0266.1D57CFD4%40web.de
(Subject: Re: standard #pragma ?)
regards,
alexander.
Peter van Merkerk
> Peter van Merkerk wrote:
> [...]
> > Any resonably competent C++ programmer knows that the behaviour of
> > #pragma is compiler specific. You don't have to take my word for it
>
> Any "reasonably competent" *C*/C++ programer knows that you're totally
> confused here as well.
Nice try, but you are changing the subject. I was talking about standard
C++ (which happens to be the topic of this newsgroup in case you didn't
notice), not C. You seem to be the one that is confused here; C++ is not
the same as C, nor is it a true superset of C. "C/C++" is to the best of
my knowledge not an existing programming language. Consequently I'm
afraid there won't be that many "C/C++" programmers around to support
your claim about my mental state.
The quote below is all what the C++ standard has to say about the pragma
directive:
"16.6 Pragma directive [cpp.pragma]
A preprocessing directive of the form
# pragma pp-tokens opt new-line
causes the implementation to behave in an implementation-defined manner.
Any pragma that is not recognized by the implementation is ignored."
But I'm sure that that quote won't change your conviction that if a
#pragma directive works on one compiler it will work on all compilers.
Have a nice day,
Peter
Alexander Terekhov
Peter van Merkerk wrote:
[...]
> C++ (which happens to be the topic of this newsgroup in case you didn't
> notice), not C.
I was talking about (referring you to) stuff on "fixing" your
lovely "standard C++, the topic of this newsgroup" using some
hypothetical (standardized in the FUTURE; ala C99) #pragma to
suppress compile/link time warnings for any really unexpected
exceptions... and, at the same time, preserving the runtime
enforcement but getting rid of totally brain-damaged unwinding
on ES violations. Got it now?
regards,
alexander.
Cy Edmunds
> [...]
> > promisses to only throw the specified exception(s). Unfortunately the
> > exception specification is not enforced at compile-time.
>
> You simply don't get it, Peter. Warnings for uncaught exceptions might
> indeed be helpful, but that shall not "outlaw" unexpected exceptions...
> hence "#pragma unexpected_exception" (go do a search, my friend).
I guess I don't get it either. You seem to be contradicting Peter's
statement that exception specifications are not enforced at compile time. Do
you think that exceptions specifications ARE enforced at compile time? And I
don't mean in some imaginary world of your own creation. I mean according to
the current C++ standard.
I have seen you post many things about this topic and so far I am 0 for n in
understanding a thing you said. You always cite some post you made in the
middle of some other forum which makes no sense out of context. Since you
seem so passionate about this topic would you mind starting from scratch and
explaining your position fully?
--
Cy
http://home.rochester.rr.com/cyhome/
<snip>
Alexander Terekhov
Cy Edmunds wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote in message
> news:3F27AEDD...@web.de...
> >
> > Peter van Merkerk wrote:
> > [...]
> > > promisses to only throw the specified exception(s). Unfortunately the
> > > exception specification is not enforced at compile-time.
> >
> > You simply don't get it, Peter. Warnings for uncaught exceptions might
> > indeed be helpful, but that shall not "outlaw" unexpected exceptions...
> > hence "#pragma unexpected_exception" (go do a search, my friend).
>
> I guess I don't get it either.
I know. But that's only because you chose to NOT follow my
"recommendation" to spend 19 bucks.
http://groups.google.com/groups?selm=3DF72917.5966CB18%40web.de
(Subject: Re: Exception specifications)
> You seem to be contradicting Peter's
> statement that exception specifications are not enforced at compile time. Do
> you think that exceptions specifications ARE enforced at compile time?
They are enforced at runtime (and that's right), but "a way" the
enforcement currently works is totally brain-damaged. Compile/link
time CHECKING might be helpful to some folks and I'd have no
problems with such thing... as long as it would provide something
along the lines of "#pragma unexpected_exception".
> And I
> don't mean in some imaginary world of your own creation. I mean according to
> the current C++ standard.
>
> I have seen you post many things about this topic and so far I am 0 for n in
> understanding a thing you said. You always cite some post you made in the
> middle of some other forum which makes no sense out of context.
You should study the context.
> Since you
> seem so passionate about this topic would you mind starting from scratch and
> explaining your position fully?
Sometime after vacation, perhaps.
regards,
alexander.
Cy Edmunds
articulate one, your posts on this subject will continue to be a complete
waste of bandwidth.
--
Cy
http://home.rochester.rr.com/cyhome/
Michael Furman
=== Start of quote from ISO/IEC 14882:
$ [cpp.pragma] 16.6 Pragma directive
1 A preprocessing directive of the form
# pragma pptokens
causes the implementation to behave in an implementationdefined
manner. Any pragma that is not recognized
by the implementation is ignored.
=== End of quote
Peter van Merkerk
> Peter van Merkerk wrote:
> [...]
> > Nice try, but you are changing the subject. I was talking about standard
> > C++ (which happens to be the topic of this newsgroup in case you didn't
> > notice), not C.
>
> I was talking about (referring you to) stuff on "fixing" your
> lovely "standard C++, the topic of this newsgroup" using some
> hypothetical (standardized in the FUTURE; ala C99) #pragma to
> suppress compile/link time warnings for any really unexpected
> exceptions
Well, that wasn't too obvious from your previous posts, and certainly not
obvious considering the OPs question or the nature of this newsgroup. The
OPs question had nothing to do with how ES will work in a future version of
C++ as envisioned by you (and only known to you). The unfortunate reality is
that many of us have to deal with C++ as it is today, including all its
flaws. Many people consider the ES in its current form is not very useful,
and some feel it is even detrimental. I'm not advocating ES should be
removed from the standard, just that given the current state of affairs ES
should be used judiciously if at all.
I get the impression that your responses are triggered by certain subjects
you have strong feelings about (like volatile, multithreading and of course
exception specifications). The motivation for responding seems to be
advocating a direction you feel the future C++ standard should take, rather
than helping the OP. I'm sure you have good ideas, but I think it would be
more effective to post those ideas to comp.std.c++.
> ... and, at the same time, preserving the runtime
> enforcement but getting rid of totally brain-damaged unwinding
> on ES violations. Got it now?
I assume you are referring to paragraph 18.6.2.4 of the C++ standard? If so,
I'm sorry to disappoint you, but at the I have no reason to disagree with
you on that one:-) But don't worry I bet there are still plenty of topics we
can disagree on.
I think you should really work on your communication skills. Your
confrontational communication style combined with little content tends to be
counterproductive. It is more likely to lead to agitated responses than a
meaningful discussion. You seem to be unable to get your points across,
which is apparently a source of frustration for you. Keep in mind that most
people are not psychic; they don't know what is going on in your own little
universe unless you explicitly explain your line of reasoning. Just giving
incomprehensible hints or dropping one liners how you feel about something
without further motivation gets people lost in no time, eventually they will
ignore you completely.
Alexander Terekhov
Peter van Merkerk wrote:
[...]
> more effective to post those ideas to comp.std.c++.
comp.std.c++:
http://google.com/groups?threadm=3EC0ECAA.6520B266%40web.de
(Subject: Exception handling... it's time to fix the standard)
http://google.com/groups?threadm=3EE08DDC.A3A7A32D%40web.de
(Subject: std0X::expected_exception<T>())
http://google.com/groups?threadm=ubrx2kstv.fsf_-_%40boost-consulting.com
(Subject: Re: std0X::expected_exception<T>() [repost])
[...]
> I think you should really work on your communication skills. ...
I'm trolling, stupid.
regards,
alexander.