Re: I wish exceptions would give you access to the stack trace
0xCDCDCDCD@gmx.at (Martin B.) wrote (abridged):
On 10.03.2011 23:52, Dave Harris wrote:
Indeed, I like my exception handling to be simple, and to not
depend very much on what the exception is. So exceptions are
the last place I'd need a stack trace.(...)
I beg to differ. Exceptions are runtime *exceptional* situations. I
would say that this means - for the average real world code base -
that they are "less tested" than the normal code path. This in
turn means that even when the work correctly, the exceptional
code path may not have sufficient information to diagnose a
problem after the fact.
That they are less tested is one reason why I think their code should be
kept simple. Trying to "diagnose a problem after the fact" from the stack
trace sounds crazy to me, and rather ad hoc and trial-and-error. You
don't give an example, beyond mentioning bad_alloc, so I still don't
understand what you actually want to do.
The proverbial "toplevel" `catch(std::exception const& e)` may for
example catch a std::bad_alloc. Without a stack trace, the
information is rather useless as you will likely have no
clue whatsoever in which part of your program you ran out of memory.
What difference does it make? For the sake of progressing the
conversation, I'll suppose that if bad_alloc happens in the UI module,
you want to ignore it, and if it happens in the network layer, you want
to retry. (I know it's a bad example, but I can't think of a good one.)
In my view, having the exception handler probe the stack trace is not the
best way to discover which module threw the exception. Better would be to
catch it at a module boundary, and wrap it with ui_bad_alloc or
network_bad_alloc.
In any case, if you are catching the bad_alloc at the top level, then I
don't see how you could retry network errors. There's basically only one
place you can catch the exception and also have enough preserved state to
retry the operation, which is low enough down that you know the exception
came from the network module.
Do you have a problem where probing the stack trace would be the
preferred solution? Or does "after the fact" mean that you are finding
design problems too late in the development process to correct the design,
and instead want to use stack traces as solution that is less than ideal
but that can be retro-fitted easily?
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]