From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM,PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Thread: 103376,e646052dc594401f
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!news4.google.com!feeder.news-service.com!newsfeed.straub-nv.de!eternal-september.org!.POSTED!not-for-mail
From: Warren <ve3wwg@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Strategies with SPARK which does not support exceptions
Date: Wed, 23 Jun 2010 16:22:16 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <Xns9DA07DD8BA13EWarrensBlatherings@81.169.183.62>
References: <op.vegat3qjule2fv@garhos>
 <93966134-a285-41c5-a7f6-8c59151718a7@k39g2000yqb.googlegroups.com>
Injection-Date: Wed, 23 Jun 2010 16:22:16 +0000 (UTC)
Injection-Info: mx01.eternal-september.org;
 posting-host="9f8M0iN5t54V+4DF/iqO8g";
	logging-data="27329"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18gd11fGYlLnr6QzFdRVIx9pJk5jM5ZgRI="
User-Agent: Xnews/5.04.25
X-Face: 
 &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j
Cancel-Lock: sha1:IS9+qb0uHrbZtJkjAM9qL9ArGkk=
Xref: g2news2.google.com comp.lang.ada:12864
Date: 2010-06-23T16:22:16+00:00
List-Id: <comp.lang.ada>

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