runtime hook for Crash on Error

[Dmitry Olshansky]

On 02.06.2012 0:06, Dmitry Olshansky wrote:
> 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.
>
>

Ah, forgot the most important thing: I'm not convinced that throwing 
Error that _loosely_ _unwinds_ stack is better then straight abort on 
spot or _proper_ stack unwinding. nothrow is not argument of itself. 
I've yet to see argument for what it gives us that so important.
(C++ didn't have proper nothrow for ages, it did worked somehow)

BTW stack can be corrupted (in fact it's quite often is, and that's most 
dangerous thing). Even C's runtime abort can be corrupted. Mission 
critical software should just use straight HALT instruction*.

So point is don't get too paranoid by default please.

Yet it will leave things that this program operates on in undefined 
state, like half-open airlock.

-- 
Dmitry Olshansky