Re: Strategies with SPARK which does not support exceptions

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

On Jun 17, 8:33 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Hello,
>
> (This topic will probably not be the most exiting topic to some people).
>
> When I use SPARK, or even when I don't use SPARK while I still have SPARK  
> design style in mind (even with Pascal which I still use), I have like any  
> one else, to forget about exceptions.

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

Who even remember having already tested the exception error handling
as the software behaviour alternative?
That is about falling within shortcuts, verifications and rescue
processing all about unpredictable/uncompleted states/operations/tasks
to not being left behind - (risks are about remaining inconsistencies
triggering blockages or instability).

Usually, large critical software applications shall process a
"Semantic Response", with "add error" or "add warning" annotation
methods and "is complete" or "is successful" checking operations.  And
generally speaking, the goal is no much about to abort something, but
let it go and collect as many errors or warnings to trace the
vulnerabilities.  Indeed, the functional behaviour would rely on
"semantic response" as a part of the system requirements, in terms of
fault tolerance: (Because, faults or failures happen, whether
internally or within interactions).

Semantic responses shall trigger a selective processing in case of
error or eventually a complementary processing in case of warning
only.

In such a case, better to use a formal language like Ada and testing
as a software development approach.


Claude Defour