Re: A few exception questions

Discussion in 'C++' started by Peter van Merkerk, Jul 30, 2003.

  1. "Marijn" <> wrote in message
    news:...
    > 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
    Peter van Merkerk, Jul 30, 2003
    #1
    1. Advertising

  2. Peter van Merkerk

    Marijn Guest

    > 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
    Marijn, Jul 30, 2003
    #2
    1. Advertising

  3. 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=
    (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=
    (Subject: Re: Guru of the Week #82: Solution)

    regards,
    alexander.

    P.S. http://groups.google.com/groups?selm=
    Alexander Terekhov, Jul 30, 2003
    #3
  4. "Alexander Terekhov" <> wrote in message
    news:...
    >
    > 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=


    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
    Peter van Merkerk, Jul 30, 2003
    #4
  5. 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=
    (Subject: Re: standard #pragma ?)

    regards,
    alexander.
    Alexander Terekhov, Jul 30, 2003
    #5
  6. Peter van Merkerk

    Cy Edmunds Guest

    "Alexander Terekhov" <> wrote in message
    news:...
    >
    > 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>
    Cy Edmunds, Jul 30, 2003
    #6
  7. Cy Edmunds wrote:
    >
    > "Alexander Terekhov" <> wrote in message
    > news:...
    > >
    > > 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=
    (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.
    Alexander Terekhov, Jul 30, 2003
    #7
  8. Peter van Merkerk

    Cy Edmunds Guest

    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/
    Cy Edmunds, Jul 30, 2003
    #8
  9. "Alexander Terekhov" <> wrote in message
    news:...
    >
    > 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=
    > (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
    Michael Furman, Jul 30, 2003
    #9
  10. "Alexander Terekhov" <> 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
    Peter van Merkerk, Jul 31, 2003
    #10
  11. Peter van Merkerk wrote:
    [...]
    > I'm sure you have good ideas, but I think it would be
    > more effective to post those ideas to comp.std.c++.


    comp.std.c++:

    http://google.com/groups?threadm=
    (Subject: Exception handling... it's time to fix the standard)

    http://google.com/groups?threadm=
    (Subject: std0X::expected_exception<T>())

    http://google.com/groups?threadm=
    (Subject: Re: std0X::expected_exception<T>() [repost])

    [...]
    > I think you should really work on your communication skills. ...


    I'm trolling, stupid.

    regards,
    alexander.
    Alexander Terekhov, Jul 31, 2003
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. William Parker
    Replies:
    3
    Views:
    559
    Hans Kesting
    Jun 25, 2004
  2. =?Utf-8?B?TmV3Ymll?=
    Replies:
    1
    Views:
    423
  3. Aaron B.
    Replies:
    2
    Views:
    6,519
    Erich Reimberg N.
    Nov 23, 2004
  4. Replies:
    10
    Views:
    548
  5. Murali
    Replies:
    2
    Views:
    559
    Jerry Coffin
    Mar 9, 2006
Loading...

Share This Page