Prev: Available C++ Libraries FAQ
Next: What's the summary of N2855 - Rvalue References and Exception Safety?
From: Goran on 6 May 2010 05:28
On May 5, 8:19 pm, "Martin B." <0xCDCDC...(a)gmx.at> wrote:
> (As opposed
> to catching, say, bad_alloc, as that will only tell me where I caught
> the exception, not where it originated.)

What a strange thing to say!

Are you suggesting, then, if you receive bad_alloc, that you should
crash? That's certainly not in the spirit of C or C++ language (I
guess that's not what you're suggesting, but it didn't come out all
that well).

And, why do you consider important where bad_alloc happened? I'd say:
if your code has a myriad of small allocations, and one of them runs
out of heap, each is a candidate, and none is important. If your code
has a small number of very big allocations, then it's easy to see
which one is it.

Also, whether something will run into OOM often depends on external
factors (e.g. other processes eat a lot of memory), that can provoke
OOM in a completely random place. If so, it's again irrelevant what
that place was. Rather, important thing is said external factor that
caused the failure.

And finally, the "where was it thrown?" question applies to any
exception, not only to bad_alloc, and also applies to any "generic"
error handling mechanism (e.g. f() failed and ERRNO is ENOMEM, but
actual call sequence was f->g->h->i (failure in "i") - what now?). My
point: it's the question of a lost context upon error, and that has to
be handled regardless of the way you approach your error reporting.

Goran.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Martin B. on 7 May 2010 03:12
Goran wrote:
> On May 5, 8:19 pm, "Martin B." <0xCDCDC...(a)gmx.at> wrote:
>> (As opposed
>> to catching, say, bad_alloc, as that will only tell me where I caught
>> the exception, not where it originated.)
>
> What a strange thing to say!
>
> Are you suggesting, then, if you receive bad_alloc, that you should
> crash? That's certainly not in the spirit of C or C++ language (I

No, I do not suggest that.

> guess that's not what you're suggesting, but it didn't come out all
> that well).
>

The point was that in the case that we are already handling another exception, it may be preferable to abort the program instead of propagating a bad_alloc.

> And, why do you consider important where bad_alloc happened? I'd say:
> ....
> point: it's the question of a lost context upon error, and that has to
> be handled regardless of the way you approach your error reporting.
>

Normally, the context would have to be provided for any old exception (by catching it at the right level).
In the case that we are getting a "double" exception (possibly bad_alloc), we have a design error/bug(*). In this case aborting with a core dump may be preferable, as that gives more context that a caught exception.

cheers,
Martin

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2
Prev: Available C++ Libraries FAQ
Next: What's the summary of N2855 - Rvalue References and Exception Safety?