runtime hook for Crash on Error

deadalnix deadalnix at gmail.com
Wed Jun 6 10:31:33 PDT 2012


Le 06/06/2012 18:56, Dmitry Olshansky a écrit :
> On 06.06.2012 20:53, Sean Kelly wrote:
>> On Jun 6, 2012, at 9:45 AM, deadalnix wrote:
>>
>>> Le 05/06/2012 18:21, Sean Kelly a écrit :
>>>> On Jun 5, 2012, at 8:44 AM, Jonathan M Davis<jmdavisProg at gmx.com>
>>>> wrote:
>>>>>
>>>>> In many cases, it's probably fine, but if the program is in a bad
>>>>> enough state
>>>>> that an Error is thrown, then you can't know for sure that any
>>>>> particular such
>>>>> block will execute properly (memory corruption being the extreme
>>>>> case), and if
>>>>> it doesn't run correctly, then it could make things worse (e.g.
>>>>> writing
>>>>> invalid data to a file, corrupting that file). Also, if the stack
>>>>> is not unwound
>>>>> perfectly (as nothrow prevents), then the program's state will become
>>>>> increasingly invalid the farther that the program gets from the
>>>>> throw point,
>>>>> which will increase the chances of cleanup code functioning
>>>>> incorrectly, as
>>>>> any assumptions that they've made about the program state are
>>>>> increasingly
>>>>> likely to be wrong (as well as it being increasingly likely that
>>>>> the variables
>>>>> that they operate on no longer being valid).
>>>>
>>>> Then we should really just abort on Error. What I don't understand
>>>> is the assertion that it isn't safe to unwind the stack on Error and
>>>> yet that catch(Error) clauses should still execute. If the program
>>>> state is really so bad that nothing can be done safely then why
>>>> would the user attempt to log the error condition or anything else?
>>>>
>>>
>>> Yes, either we consider the environement may have been compromised
>>> and it don't even make sense to throw an Error, or we consider this
>>> environement is still consistent, and we have a logic bug. If so,
>>> scope (especially failure) should run when stack is unwinded.
>>>
>>> As need depend on the software (an office suite should try its best
>>> to fail gracefully, a plane autpilot should crash ASAP and give
>>> control back to the pilot), what is needed here is a compiler switch.
>>
>> I think a runtime hook is reasonable instead. But the default case has
>> to be the more permissive case.
>> It's safe to tighten the rules but never to loosen them, since
>> external code will be written assuming the default behavior.
>
> Yes, that's what I had in mind when I renamed topic to "runtime hook for
> Crash on Error". Default should be treat Error as just another type of
> throwable that is logically not caught by catch(Exception).
>

A better alternative is the condition system, inspired by LISP and 
proposed by H. S. Teoh . I definitively make sense in this case, and a 
better solution than both your and my proposal.


More information about the Digitalmars-d mailing list