DIP33: A standard exception hierarchy

[Dmitry Olshansky]

02-Apr-2013 00:34, Ali Çehreli пишет:
> On 04/01/2013 12:44 PM, Dmitry Olshansky wrote:> 01-Apr-2013 20:00, John
> Colvin пишет:
>
>  >> Therefore, you're better off not trying to cleanup if program state
>  >> could be invalid.
>  >
>  > Data is corrupted no matter if you just fail to write it in a consistent
>  > state (sudden assertion in some 3-rd party library) or corrupt
>  > accidentally by bad write (during cleanup on corrupted RAM).
>
> The failed assertion may be the moment when the program detects that
> something is wrong. A safe program should stop doing anything else.

And that's precisely the interesting moment. It should stop but the 
definition of "stop" really depends on many factors. Just pretending 
that calling abort is a panacea is totally wrong IMO.

BTW what do you exactly mean by "safe" program?

>  > Therefore you should always try to orderly cleanup but do not rely on it
>  > to actually work at all circumstances (thus backups, commits/save
>  > points, watchdogs and whatnot).
>
> A safe program must first guarantee that that cleanup is harmless, which
> is not possible when the program is in an invalid state.

There could a lot of ways to do that even in "illegal" state. Restore 
and conservative reconstruction of valid state is often possible (like 
restoring files on a faulty hard drive) with a help of certain tricks 
you can get high estimates of these actions to succeed.

Once you have resigned yourself to black and white - valid /invalid 
there is no way to go indeed.

> Imagine sending
> almost infinite number of "cleanup" commands to a device that can harm
> people who are around it.

These are far better off with built-in hardware fail-safe switches and 
redundant circuitry.

Just suddenly stopping the program in the control of a spinning blade 
that cuts through somebody's tissue is not good enough.

>
> Ali
>


-- 
Dmitry Olshansky