Re: Strategies with SPARK which does not support exceptions

[Warren <ve3wwg@gmail.com>]

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

> When I use SPARK, or even when I don't use SPARK while I still have
> SPARK  design style in mind (even with Pascal which I still use), I
> have like any  one else, to forget about exceptions.
> 
> The only one thing which seems simple and clean enough I could figure,
> is  to use a Boolean variable, named "OK", and a sequence of "if
> OK then" statements. ...
> 
> Although this seems clean and maintainable enough to me so far, I was 
> still wondering how other people deal with this (and may be by the
> way, I  may have comment about why my way could be bad in some way).

While I'm not a SPARK user, a similar issue exists when writing
C code (although you can implement an exception with longjmp()).

In C, the best approach seems to be to have a defined set of
error/status codes to return. Often the errno values (e.g. EINVAL)
are used. But you can define a better enum set dedicated to 
your application's specific needs.

In Ada, you can vastly improve upon that using a "real" enumerated
type.  You can then define as many enum types as you need for
each class of function/procedures.

I suggest this because the calling program usually needs to
know "why" the call failed. 

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