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

Claude expounded in news:d90f60dd-b74f-4eff-b9d8-803ebb64c9d2
@z8g2000yqz.googlegroups.com:

> On Jun 23, 9:22�am, Warren <ve3...@gmail.com> wrote:
> Exceptions are not the best way to process error. (i.e., Not just a
> SPARK topic).

Well, I still think this is debatable (for run of the mill 
code). I haven't seen conclusive arguments for either side.

>> 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 disastrous.
> 
> Warren, you got quite the point, proceeding incorrectly may be
> disastrous.
> But not equally, because when the exception handler doesn't proceed
> correctly and gets another exception, what's going to happen next?

I could counter that the non-exception code can continue
on blithely as if nothing went wrong.  What then?

At some point, you just have to accept some level of code 
responsibility (as a practical matter). With either 
approach, you cannot entirely avoid disasters.

> Safety critical system won't like any exception...
> That's one of the SPARK advantage, it can assess about the absence of
> run-time errors.
> But about operational hazards, that's another story (worst: the
> semantic responses are used to be generic!)
> 
> Claude Defour

I can see some definite advantage for "proving" that
a system works under all expected cases. But the 
responsibility then just shifts to the proof testing,
making sure that you've covered all possible real life
conditions. The Arian disaster comes to mind. ;-)

But you're right in that if you can prove that all the
bases are covered, you are ahead of the game. You don't
have to worry that some unanticipated exception (and
possible mishandling) may occur.

So I suppose that I do agree with you, provided you 
are rigourous in your proofs. But for run of the mill 
stuff (that I work on), where that kind of testing is 
not done, then exceptions are in my mind "good enough", 
and perhaps even preferred.

Warren