Re: Catching exceptions, bad alloc revisited

Discussion in 'C++' started by red floyd, Sep 9, 2011.

  1. red floyd

    red floyd Guest

    On 9/9/2011 1:59 PM, Paul wrote:
    > If I have a function which allocates memory and uses a try-catch block
    > to do allocation it can then either handle any thrown exception or it
    > can re-throw it. However if I don't bother to catch this exception will
    > any code that uses the function be able to catch this exception and
    > handle any potential errors?


    Yes, exceptions propagate up the call stack until caught, or until they
    don't get caught in main(), at which point std::terminate() gets called.
     
    red floyd, Sep 9, 2011
    #1
    1. Advertising

  2. red floyd

    Paul Guest

    On Sep 9, 10:49 pm, red floyd <> wrote:
    > On 9/9/2011 1:59 PM, Paul wrote:
    >
    > > If I have a function which allocates memory and uses a try-catch block
    > > to do allocation it can then either handle any thrown exception or it
    > > can re-throw it. However if I don't bother to catch this exception will
    > > any code that uses the function be able to catch this exception and
    > > handle any potential errors?

    >
    > Yes, exceptions propagate up the call stack until caught, or until they
    > don't get caught in main(), at which point std::terminate() gets called.


    Yes I believe this is the case unless a destructor throws an uncaught
    exception during unwinding, when terminate will be called before
    reaching main. If this is true is is probably better to use the
    set_terminate function if you wanted your program to display a dying
    message or something, rather than wrapping everything in a try block
    in main which I've seen others suggest.
    Is set_terminate standard?

    What I am trying to underdstand about all this is the way STL member
    functions such as allocator constructor has and empty exception
    specifier after it i.e:
    allocator() throw()

    What is the point in having an empty specifier , isn't it just the
    same as having no specifier at all?
    What I think is that this is just a form of documenting the function
    to say there is a chance it may throw and exception and it has no
    technical purpose at all, would i be right to think that?
     
    Paul, Sep 10, 2011
    #2
    1. Advertising

  3. On Sep 10, 5:47 am, Paul <> wrote:
    > On Sep 9, 10:49 pm, red floyd <> wrote:
    > > On 9/9/2011 1:59 PM, Paul wrote:


    > > > If I have a function which allocates memory and uses a try-catch block
    > > > to do allocation it can then either handle any thrown exception or it
    > > > can re-throw it. However if I don't bother to catch this exception will
    > > > any code that uses the function be able to catch this exception and
    > > > handle any potential errors?

    >
    > > Yes, exceptions propagate up the call stack until caught, or until they
    > > don't get caught in main(), at which point std::terminate() gets called..

    >
    > Yes I believe this is the case unless a destructor throws an uncaught
    > exception during unwinding, when terminate will be called before
    > reaching main.


    yes but you should make sure your destructors don't do this.


    > If this is true is is probably better to use the
    > set_terminate function if you wanted your program to display a dying
    > message or something, rather than wrapping everything in a try block
    > in main which I've seen others suggest.
    > Is set_terminate standard?


    yes. 10s of googling to confirm this

    > What I am trying to underdstand about all this is the way STL member
    > functions such as allocator constructor has and empty exception
    > specifier after it i.e:
    > allocator() throw()


    sounds odd

    > What is the point in having an empty specifier , isn't it just the
    > same as having no specifier at all?


    no.It means the function doesn't throw. Which seems an unlikely
    property of an allocator. Do you mean the template parameter that's
    spelled "alloc"?


    > What I think is that this is just a form of documenting the function
    > to say there is a chance it may throw and exception and it has no
    > technical purpose at all, would i be right to think that?


    no, I don't think so
     
    Nick Keighley, Sep 10, 2011
    #3
  4. red floyd

    Paul Guest

    On Sep 10, 3:15 pm, Nick Keighley <>
    wrote:
    > On Sep 10, 5:47 am, Paul <> wrote:
    >
    > > On Sep 9, 10:49 pm, red floyd <> wrote:
    > > > On 9/9/2011 1:59 PM, Paul wrote:
    > > > > If I have a function which allocates memory and uses a try-catch block
    > > > > to do allocation it can then either handle any thrown exception or it
    > > > > can re-throw it. However if I don't bother to catch this exception will
    > > > > any code that uses the function be able to catch this exception and
    > > > > handle any potential errors?

    >
    > > > Yes, exceptions propagate up the call stack until caught, or until they
    > > > don't get caught in main(), at which point std::terminate() gets called.

    >
    > > Yes I believe this is the case unless a destructor throws an uncaught
    > > exception during unwinding, when terminate will be called before
    > > reaching main.

    >
    > yes but you should make sure your destructors don't do this.
    >
    > > If this is true is is probably better to use the
    > > set_terminate function if you wanted your program to display a dying
    > > message or something, rather than wrapping everything in a try block
    > > in main which I've seen others suggest.
    > > Is set_terminate standard?

    >
    > yes. 10s of googling to confirm this
    >
    > > What I am trying to underdstand about all this is the way STL member
    > > functions such as allocator constructor has and empty exception
    > > specifier after it i.e:
    > > allocator() throw()

    >
    > sounds odd
    >
    > > What is the point in having an empty specifier , isn't it just the
    > > same as having no specifier at all?

    >
    > no.It means the function doesn't throw. Which seems an unlikely
    > property of an allocator. Do you mean the template parameter that's
    > spelled "alloc"?

    Oh right , I was thinking that throw() was telling me it threw
    something, but this means it doesn't throw anything. Thanks.

    I'm talking about the class template for std::allocator, the
    constructor is referenced here:
    http://www.cplusplus.com/reference/std/memory/allocator/allocator/

    Seems weird how copying an allocator can guarantee to not throw, but
    it's right enough because there are no data members to initialise.
     
    Paul, Sep 10, 2011
    #4
    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. Marina
    Replies:
    2
    Views:
    478
    Marina
    Jul 8, 2003
  2. Amil Hanish
    Replies:
    0
    Views:
    552
    Amil Hanish
    Apr 13, 2006
  3. Adam Maass
    Replies:
    5
    Views:
    407
    Sudsy
    Jul 22, 2003
  4. rantingrick
    Replies:
    44
    Views:
    1,227
    Peter Pearson
    Jul 13, 2010
  5. Paul

    bad alloc

    Paul, Aug 30, 2011, in forum: C++
    Replies:
    168
    Views:
    2,571
Loading...

Share This Page