Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: A few exception questions

Reply
Thread Tools

Re: A few exception questions

 
 
Peter van Merkerk
Guest
Posts: n/a
 
      07-30-2003
"Marijn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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....-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


 
Reply With Quote
 
 
 
 
Marijn
Guest
Posts: n/a
 
      07-30-2003
> No that its not the case, a missing 'throw' specification does not mean
> 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

 
Reply With Quote
 
 
 
 
Alexander Terekhov
Guest
Posts: n/a
 
      07-30-2003

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...2F8B2%40web.de
(Newsgroups: comp.lang.c++.moderated)

> http://www.boost.org/more/lib_guide....-specification


http://article.gmane.org/gmane.comp....st.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...D2587%40web.de
(Subject: Re: Guru of the Week #82: Solution)

regards,
alexander.

P.S. http://groups.google.com/groups?selm...F5B69%40web.de
 
Reply With Quote
 
Peter van Merkerk
Guest
Posts: n/a
 
      07-30-2003
"Alexander Terekhov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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...2F8B2%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



 
Reply With Quote
 
Alexander Terekhov
Guest
Posts: n/a
 
      07-30-2003

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.

http://groups.google.com/groups?selm...7CFD4%40web.de
(Subject: Re: standard #pragma ?)

regards,
alexander.
 
Reply With Quote
 
Cy Edmunds
Guest
Posts: n/a
 
      07-30-2003
"Alexander Terekhov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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. 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>


 
Reply With Quote
 
Alexander Terekhov
Guest
Posts: n/a
 
      07-30-2003

Cy Edmunds wrote:
>
> "Alexander Terekhov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > 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...6CB18%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.
 
Reply With Quote
 
Cy Edmunds
Guest
Posts: n/a
 
      07-30-2003
You may have some good ideas here. I don't know. But until you can
articulate one, your posts on this subject will continue to be a complete
waste of bandwidth.

--
Cy
http://home.rochester.rr.com/cyhome/


 
Reply With Quote
 
Michael Furman
Guest
Posts: n/a
 
      07-30-2003

"Alexander Terekhov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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.
>
> http://groups.google.com/groups?selm...7CFD4%40web.de
> (Subject: Re: standard #pragma ?)
>


=== 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





 
Reply With Quote
 
Peter van Merkerk
Guest
Posts: n/a
 
      07-30-2003
"Alexander Terekhov" <(E-Mail Removed)> wrote:
> 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.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Internet connects for a few seconds then disconnects for a few sec Cody Wireless Networking 2 06-28-2009 08:24 PM
Exception of type 'System.Web.HttpUnhandledException' wasthrown.Exception has been thrown by the target of an invocation.System.WebSystem.Exception jobs ASP .Net 1 11-16-2007 05:57 PM
while executing my client program i get the exception javax.naming.LinkException: [Root exception is javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException: remaining if plz anybody know how to solve this problem then mahesh Java 0 03-08-2007 12:26 PM
Few Questions (HW questions already answered by me) padh.ayo@gmail.com C Programming 10 12-06-2006 05:48 PM
To delete few lines and add few lines at the end of a text file using c program Murali C++ 2 03-09-2006 04:45 PM



Advertisments