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<[email protected]>
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.
