What happens when an exception is not caught?

Discussion in 'C++' started by Digital Puer, Aug 23, 2007.

  1. Digital Puer

    Digital Puer Guest

    Sorry for the rudimentary question. I found the following posting
    online and did not know the answer myself.


    "Reminds me of a time I had a phone interview concerning a C++ job.
    Didn't help that the interviewer had a very thick Slavic accent. He
    asked me what happens when an exception doesn't get caught. I told him
    the program would terminate. He said that's not the answer he was
    looking for. I gave him a kind of detailed description of the throw
    process leading to "then it gets to the top level of the program and
    if there is no exception handling there, the program terminates." He
    said "no, what I was looking for is that the unhandledExceptionHandler
    is called" (might not have the correct name.)"


    Is there a default exception handler?
     
    Digital Puer, Aug 23, 2007
    #1
    1. Advertising

  2. On 2007-08-23 21:21, Digital Puer wrote:
    > Sorry for the rudimentary question. I found the following posting
    > online and did not know the answer myself.
    >
    >
    > "Reminds me of a time I had a phone interview concerning a C++ job.
    > Didn't help that the interviewer had a very thick Slavic accent. He
    > asked me what happens when an exception doesn't get caught. I told him
    > the program would terminate. He said that's not the answer he was
    > looking for. I gave him a kind of detailed description of the throw
    > process leading to "then it gets to the top level of the program and
    > if there is no exception handling there, the program terminates." He
    > said "no, what I was looking for is that the unhandledExceptionHandler
    > is called" (might not have the correct name.)"
    >
    >
    > Is there a default exception handler?


    Yes, the terminate() function is called, the user can specify a function
    to be called by terminate(), however this function is not allowed to
    return, but must terminate execution of the program. But it is allowed
    to do some other stuff first.

    --
    Erik Wikström
     
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Aug 23, 2007
    #2
    1. Advertising

  3. Digital Puer wrote:
    > Sorry for the rudimentary question. I found the following posting
    > online and did not know the answer myself.
    >
    >
    > "Reminds me of a time I had a phone interview concerning a C++ job.
    > Didn't help that the interviewer had a very thick Slavic accent. He
    > asked me what happens when an exception doesn't get caught. I told him
    > the program would terminate. He said that's not the answer he was
    > looking for. I gave him a kind of detailed description of the throw
    > process leading to "then it gets to the top level of the program and
    > if there is no exception handling there, the program terminates." He
    > said "no, what I was looking for is that the unhandledExceptionHandler
    > is called" (might not have the correct name.)"
    >
    >
    > Is there a default exception handler?


    The default "unhandled exception handler" is "std::terminate". The
    Standard describes the cases in which it's called in [except.terminate]
    (15.5.1 in the current edition).

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 23, 2007
    #3
  4. Digital Puer

    Just me Guest

    On Thu, 23 Aug 2007 12:21:38 -0700, Digital Puer wrote:

    > Is there a default exception handler?



    or you can make sure that any exception is caught by using


    try {}
    catch(exception_type_a a) {}
    catch(exception_type_b b) {}
    catch(exception_type_c c) {}
    catch(...) {}

    the (...) means catch any uncaught exception that is thrown in the try
    block

    otherwise, as others have mentioned, the terminate() function can provide
    a graceful exit from your program.
     
    Just me, Aug 24, 2007
    #4
  5. Hi!

    Erik Wikström schrieb:
    > Yes, the terminate() function is called, the user can specify a function
    > to be called by terminate(), however this function is not allowed to
    > return, but must terminate execution of the program. But it is allowed
    > to do some other stuff first.


    What is the state of global variables in a terminate handler which is
    installed by set_terminate? Are they destructed prior to entering the
    handler?

    Frank
     
    Frank Birbacher, Aug 24, 2007
    #5
  6. Frank Birbacher wrote:
    > [..]
    > What is the state of global variables in a terminate handler which is
    > installed by set_terminate? Are they destructed prior to entering the
    > handler?


    It's not really specified, but since the default terminate_handler is
    'abort' and destructors of static objects are not called priort to
    'abort' (if called by the user), they will likely not be called prior
    to the call to your terminate_handler, either.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 24, 2007
    #6
  7. Hi!

    Victor Bazarov schrieb:
    > It's not really specified, but since the default terminate_handler is
    > 'abort' and destructors of static objects are not called priort to
    > 'abort' (if called by the user), they will likely not be called prior
    > to the call to your terminate_handler, either.


    Does then (or should) abort() care for destruction of globals? Or is it
    that the destructors are never run in this case?

    Frank
     
    Frank Birbacher, Aug 25, 2007
    #7
  8. Frank Birbacher wrote:
    > Hi!
    >
    > Victor Bazarov schrieb:
    >> It's not really specified, but since the default terminate_handler is
    >> 'abort' and destructors of static objects are not called priort to
    >> 'abort' (if called by the user), they will likely not be called prior
    >> to the call to your terminate_handler, either.

    >
    > Does then (or should) abort() care for destruction of globals? Or is
    > it that the destructors are never run in this case?


    It's up to the implementors of the library whether 'abort' should care
    for destruction of globals. As to your own 'terminate_handler', it is
    up to you, but in most cases you won't be able to do anything except
    [attempt] to call 'exit' instead of 'abort', but since your handler is
    called in a funky state of the program, I am not sure calling 'exit'
    is actually a good idea.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 25, 2007
    #8
  9. Digital Puer

    Dilip Guest

    On Aug 24, 7:11 pm, "Victor Bazarov" <> wrote:
    > Frank Birbacher wrote:
    > > Hi!

    >
    > > Victor Bazarov schrieb:
    > >> It's not really specified, but since the default terminate_handler is
    > >> 'abort' and destructors of static objects are not called priort to
    > >> 'abort' (if called by the user), they will likely not be called prior
    > >> to the call to your terminate_handler, either.

    >
    > > Does then (or should) abort() care for destruction of globals? Or is
    > > it that the destructors are never run in this case?

    >
    > It's up to the implementors of the library whether 'abort' should care
    > for destruction of globals. As to your own 'terminate_handler', it is
    > up to you, but in most cases you won't be able to do anything except
    > [attempt] to call 'exit' instead of 'abort', but since your handler is
    > called in a funky state of the program, I am not sure calling 'exit'
    > is actually a good idea.


    Incidentally somebody posted a test case explaining this exact
    situation at c.l.c++.m. See here:
    http://groups.google.com/group/comp.lang.c .moderated/msg/d174d65d0a890bae
     
    Dilip, Aug 25, 2007
    #9
  10. Digital Puer

    Dilip Guest

    On Aug 24, 7:11 pm, "Victor Bazarov" <> wrote:
    > Frank Birbacher wrote:
    > > Hi!

    >
    > > Victor Bazarov schrieb:
    > >> It's not really specified, but since the default terminate_handler is
    > >> 'abort' and destructors of static objects are not called priort to
    > >> 'abort' (if called by the user), they will likely not be called prior
    > >> to the call to your terminate_handler, either.

    >
    > > Does then (or should) abort() care for destruction of globals? Or is
    > > it that the destructors are never run in this case?

    >
    > It's up to the implementors of the library whether 'abort' should care
    > for destruction of globals. As to your own 'terminate_handler', it is
    > up to you, but in most cases you won't be able to do anything except
    > [attempt] to call 'exit' instead of 'abort', but since your handler is
    > called in a funky state of the program, I am not sure calling 'exit'
    > is actually a good idea.


    Incidentally somebody posted a test case explaining this exact
    scenario at c.l.c++.m. See here:
    http://groups.google.com/group/comp.lang.c .moderated/msg/d174d65d0a890bae
     
    Dilip, Aug 25, 2007
    #10
  11. * Victor Bazarov:
    > Frank Birbacher wrote:
    >> Hi!
    >>
    >> Victor Bazarov schrieb:
    >>> It's not really specified, but since the default terminate_handler is
    >>> 'abort' and destructors of static objects are not called priort to
    >>> 'abort' (if called by the user), they will likely not be called prior
    >>> to the call to your terminate_handler, either.

    >> Does then (or should) abort() care for destruction of globals? Or is
    >> it that the destructors are never run in this case?

    >
    > It's up to the implementors of the library whether 'abort' should care
    > for destruction of globals.


    Sorry, that's incorrect.

    §3.6.3/4 abort() ... "terminates the program without executing
    destructors for objects of automatic or static storage duration and
    without calling the functions passed to atexit()."

    In short, abort() does not execute destructors, nor exit-functions.


    > As to your own 'terminate_handler', it is
    > up to you, but in most cases you won't be able to do anything except
    > [attempt] to call 'exit' instead of 'abort', but since your handler is
    > called in a funky state of the program, I am not sure calling 'exit'
    > is actually a good idea.


    Agreed.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Aug 25, 2007
    #11
  12. Digital Puer

    Jerry Coffin Guest

    In article <>,
    says...

    [ ... ]

    > otherwise, as others have mentioned, the terminate() function can provide
    > a graceful exit from your program.


    ....at least if you consider being dragged out by the heels after being
    shot in the head a "graceful exit". :)

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Aug 26, 2007
    #12
    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. Ola
    Replies:
    0
    Views:
    535
  2. Tedka
    Replies:
    2
    Views:
    2,675
    Mr. Dot Net
    Jul 19, 2004
  3. Axel Dahmen

    Exception Not Caught on Production Server

    Axel Dahmen, Apr 21, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    382
    Axel Dahmen
    Apr 21, 2005
  4. NM
    Replies:
    6
    Views:
    471
    Default User
    Sep 20, 2006
  5. Replies:
    1
    Views:
    285
    Zeppe
    Jun 22, 2007
Loading...

Share This Page