SHORT Re: Suggestion: "fix" assert(obj)

[Jascha Wetzel]

Martin Howe wrote:
> Well, FWIW, IMO it does -- the printf is endoscope surgery...

oh, ok, sorry - i (mis)understood it the other way around.

> I must admit, the *routine* use of debugger sounds like something that with 
> a bit of discipline might be worth adopting; it still feels like overkill, 
> but then I guess I just haven't worked in a sector where impenetrable errors 
> are common daily occurences.

for native executables, some information is provided exclusively by the 
debugger (or other tools) that VMs give you out of the box, namely stack 
traces. therefore it's plausible, that debuggers are more commonly used 
in native programming.

>> and that's what memory dumps and post-mortem debugging is for.
>> the client sends you the dump and you can debug the exact instance of the 
>> crash.
> Now that *is* scary; the sort of things one expects the top 5% of 
> bleeding-edge expert programmers (which I freely admit to not being one of) 
> to do; certainly wasn't covered by even 3rd-year undergrad stuff; any good 
> web references you can point me to?

actually it's less scary for the client than helping the developer to 
find the problem using log information or Java stacktraces. in most 
cases it's also easier than trying to describe how to reproduce the problem.

every WinXP user knows the "bla.exe has encountered a problem and needs 
to close"-dialog with the "Send Error Report" and "Don't Send" Buttons.
what it does is creating a minidump and sending it to MS's crash 
statistics server.
instead of letting the default dialog pop up, you can replace it with 
your own or simply save the dump to a file.
Here is more info on that:
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp

as of now, D applications catch all exceptions and print their message. 
therefore no D application will trigger that crash handler. upcoming 
releases of Ddbg will allow you to deal with minidumps properly, though.