runtime hook for Crash on Error

[Dmitry Olshansky]

On 01.06.2012 23:38, Jonathan M Davis wrote:
> On Friday, June 01, 2012 14:00:01 deadalnix wrote:
>> Le 01/06/2012 12:26, Walter Bright a écrit :
>>> Except that you do not know why the arithmetic turned out wrong - it
>>> could be the result of memory corruption.
>>
>> Yes. wrong calculation often comes from memory corruption. Almost never
>> from programmer having screwed up in the said calculation.
>>
>> It is so perfectly reasonable and completely match my experience. I'm
>> sure everybody here will agree.
>>
>> Not to mention that said memory corruption obviously come from compiler
>> bug. As always. What programmer does mistakes in his code ? We write
>> programs, not bugs !
>
> I'd have to agree that the odds of an arithmetic error being caused by memory
> corruption are generally quite low, but the problem is that when an assertion
> fails, there's _no_ way for the program to know how bad things really are or
> what the cause is.

Indeed it's quite bad to assume both extremes - either "oh, my god 
everything is corrupted" or "blah, whatever, keep going". I thought D 
was trying to hold keep reasonable compromises where possible.

By the way memory corruption is checkable. And even recoverable, one 
just needs to have certain precautions like adding checksums or better 
yet ECC codes to _every_ important data structure (including of course 
stack security hashes). Seems very useful for compiler generated code 
with '-debug' switch. It even can ask GC to recheck ECC on every GC 
datastructure. Do that memory check on each throw of error dunno. Trust 
me to do the thing manually I dunno. Provide some options, damn it.

For all I care the program is flawless it's cosmic rays that are funky 
in this area.

Certain compilers by the way already do something like that on each 
stack entry/leave in debug mode (stack hash sums).

P.S. Trying to pour more and more of "generally impossible" "can't do 
this", "can't do that" and ya-da-ya-da doesn't help solving problems.


-- 
Dmitry Olshansky