«

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.

On Sep 9, 10:49*pm, red floyd <no.spam.h...@its.invalid> 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?

On Sep 10, 5:47*am, Paul <pchris...@yahoo.co.uk> wrote:
> On Sep 9, 10:49*pm, red floyd <no.spam.h...@its.invalid> 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

On Sep 10, 3:15*pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Sep 10, 5:47*am, Paul <pchris...@yahoo.co.uk> wrote:
>
> > On Sep 9, 10:49*pm, red floyd <no.spam.h...@its.invalid> 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/s...tor/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.