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,UTF8
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!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: Mon, 21 Jun 2010 13:31:18 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <Xns9D9E60DC6F348WarrensBlatherings@188.40.43.230>
References: <op.vegat3qjule2fv@garhos>
 <Xns9D9A86312F108WarrensBlatherings@81.169.183.62> <op.vegih2owule2fv@garhos>
Injection-Date: Mon, 21 Jun 2010 13:31:18 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="9f8M0iN5t54V+4DF/iqO8g";
	logging-data="24423"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18M/MzmV1yR0i6B2e72I3Kxn9OkM8UvvXk="
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:0lQA+3KZSI/YadgMPf7vTttRKe0=
Xref: g2news2.google.com comp.lang.ada:12818
Date: 2010-06-21T13:31:18+00:00
List-Id: <comp.lang.ada>

=?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
news:op.vegih2owule2fv@garhos: 

> Le Thu, 17 Jun 2010 19:11:29 +0200, Warren <ve3wwg@gmail.com> a
> écrit: 
>> It is often not sufficient to simply know that OK is false.
>> For example, wouldn't it be nice for the user to know that
>> the open failed because of permissions, instead of the file
>> not existing.
>>
>> Warren

> I see what you mean (I like the C analogy for this, that is
> meaningful),  while I don't fully agree with this later point : an
> exception typically  do not holds such details. 

Agreed and I was not promoting exceptions per se (to start with,
they are clumsy in C (with longjmp) due to the need to intercept
and do your own "cleanup" (effectively destructors).

> The exception says
> “If fails”, and don't say  why (or just sightly, via its ID).
> Don't confuse Ada exception mechanism  with other OO exception
> mechanisms, which comes with many and too much  (because unusable in
> real life) members to hold informations about the  exception
> occurence. 

Exceptions are ok for things that rarely occur, IMO. In Ada they
can be convenient, but it depends upon your application. For
example, a Not_Found exception is sufficient for my use, if I am
looking up a symbol table (map container in a wrapper) and it 
does not exist. I realize that it can incur overhead, depending
upon build options.  This works because the invoking program
already has the context info (it knows the symbol it tried to
look up).

> By the way, you are talking about propagated exceptions (as you talked
>  about callers). I did not already set up a strategy for this. 

Like I said above, I was not really considering exceptions. 
But exceptions can be tricky if they unwind through several 
layers. For example, in my current project, I usually need to
intercept them to make sure that certain reference counts are
properly unreferenced.  This applies only to objects that do
not have a Finalize method.

..
> CPU status registers), but  I'm afraid this may not be safe (while
> luckily, SPARK can help a lot to  properly use global variables ;) ).

Does SPARK even permit exceptions? I'm too lazy to
look it up.

Warren