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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: Strategies with SPARK which does not support exceptions Date: Thu, 17 Jun 2010 17:11:29 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Thu, 17 Jun 2010 17:11:29 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="9f8M0iN5t54V+4DF/iqO8g"; logging-data="21670"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/g5fEtPuBQx4ESE8QOz1lve390ho1ETxI=" 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:Amb0cuLpObmEXX3aHHQVz4FE3vk= Xref: g2news1.google.com comp.lang.ada:11802 Date: 2010-06-17T17:11:29+00:00 List-Id: =?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