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: 2218 bytes --]

=?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