Re: [boost] Re: Re: Re: improved assertions?

From: Greg Colvin (greg_at_[hidden])
Date: 2002-06-14 22:22:03

At 08:22 PM 06/14/2002, you wrote:

>From: "Ted Byers" <r.ted.byers_at_[hidden]>
>> "David Abrahams" <david.abrahams_at_[hidden]> wrote in message
>> news:0a7a01c213f6$ff88e780$6601a8c0_at_boostconsulting.com...
>> > Example 1: assertions. By the time the stack is unwound much
>information
>> is
>> > lost. On Unix, for example, you want a core dump, not an exception. On
>> > Windows you also don't want stack unwinding, though the case is a
>little
>> > more complicated there.
>> >
>> What I would be inclined to do with assertions is collect as much
>> information as I can at the point where the assertion failed:
>presumably, a
>> clever programmer could capture this information that would be lost by
>the
>> time the stack is unwound.  I'd have to rely on someone like you to tell
>me
>> how to capture that information, and then I'd package it in one of my
>> traceable exceptions which can then give me my trace information.
>
>
>On systems where there's a built-in facility for that (Windows, Unix),
>anything you can do yourself is going to be vastly inferior to what the
>system can give you by default. On Windows you get JIT debugging, which
>invokes a debugger on the program with (if you know the right tricks) the
>entire program state preserved. On Unix, a core dump is a debuggable image
>of the program state.
>
>I would never trade what's supplied by the platform for a cumbersome
>intrusive facility that requires manual intervention.

Consider long-running programs that cannot be debugged
while in production use, like the Oracle server.  If
we didn't capture readable stack traces and memory dumps
of crashed production servers we would have no way of
diagnosing bugs that get through our review and testing
and into the field.  And, yes, sad to say, we use a
cumbersome intrusive facility that requires manual
intervention.