Re: Strategies with SPARK which does not support exceptions

[Claude <claude.defour@orange.fr>]

On Jun 23, 9:22 am, Warren <ve3...@gmail.com> wrote:

Exceptions are not the best way to process error. (i.e., Not just a
SPARK topic).

> The downside of exceptions though, is that it requires
> extensive testing to provoke them (or to prove they
> don't occur).  So in a life-critical application, there
> may be the requirement that it not throw its hands in
> the air and give up (per exception). On the other hand,
> proceeding incorrectly may be equally disastrous.
>
> So my point is that there are two valid approaches and
> that "one size does not fit all".
>
> Warren

Warren, you got quite the point, proceeding incorrectly may be
disastrous.
But not equally, because when the exception handler doesn't proceed
correctly and gets another exception, what's going to happen next?
Getting a third exception in a row, and so on ...
Processing anything within an exception handler is not recommended.
(That can even requires extra procedures to correct state/data which
could become out of context/visibility).

Safety critical system won't like any exception...
That's one of the SPARK advantage, it can assess about the absence of
run-time errors.
But about operational hazards, that's another story (worst: the
semantic responses are used to be generic!)

Claude Defour