Re: Strategies with SPARK which does not support exceptions

[Warren <ve3wwg@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

Claude expounded in
news:93966134-a285-41c5-a7f6-8c59151718a7@k39g2000yqb.googlegroups.com: 

> On Jun 17, 8:33�am, Yannick Duch�ne (Hibou57)
> <yannick_duch...@yahoo.fr> wrote:
..
>> 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).

This is an area of "contraversy". So much disagreement
will be the norm here.

> 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.  
> Claude Defour

This is certainly "one way" to check a "returned result".  The 
problem with this approach however is to make certain
you test _all_ possible return cases. This can be done in Ada 
with strict use of enumerated types, provided that:

1) the case statement(s) don't use the "with other" clause, 
   allowing the compiler to warn you about missing cases.
2) the enumerated set isn't huge leading to obscurity, or
   a tendency to use "case ... with other" clause.
3) the enumerated type is suitable (i.e. isn't overloaded thru
   re-use from other calls, providing other status cases that 
   don't apply to the current one).

I see two problems with this:

1) _may_ lead to many enumerated types
2) if not strictly followed, unhandled cases are silently accepted.
3) when a problem is noticed (unhandled case), it is very difficult 
   to track it down (debugging time).

Exceptions have the advantage that:

1) they get reported and "noticed" _immediately_ when unhandled.
2) they usually report the origin of the problem in the code.

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 disasterous.

So my point is that there are two valid approaches and 
that "one size does not fit all".

Warren