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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news-1.dfn.de!news.dfn.de!news.uni-weimar.de!medsec1.medien.uni-weimar.de!lucks From: Stefan.Lucks@uni-weimar.de Newsgroups: comp.lang.ada Subject: Re: Problems with SPARK 2015 and XMLAda Date: Fri, 21 Aug 2015 10:19:50 +0200 Organization: Bauhaus-Universitaet Weimar Message-ID: References: <6952b70d-a9bc-4d0a-beb5-1cd38d6a3318@googlegroups.com> <9d3dc132-4e1a-4e9c-bcd4-82a42a73745f@googlegroups.com> NNTP-Posting-Host: medsec1.medien.uni-weimar.de Mime-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1294552761-1440144366=:23241" X-Trace: pinkpiglet.scc.uni-weimar.de 1440145774 22675 141.54.178.228 (21 Aug 2015 08:29:34 GMT) X-Complaints-To: news@pinkpiglet.scc.uni-weimar.de NNTP-Posting-Date: Fri, 21 Aug 2015 08:29:34 +0000 (UTC) X-X-Sender: lucks@debian In-Reply-To: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Content-ID: Xref: news.eternal-september.org comp.lang.ada:27544 Date: 2015-08-21T10:19:50+02:00 List-Id: --8323329-1294552761-1440144366=:23241 Content-Type: text/plain; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Fri, 21 Aug 2015, Dmitry A. Kazakov wrote: I wrote: >> The strong case that programmers just tend to forget handling them, or >> even intentionally ignore them. This is why error codes are evil. >> >> But this is a non-issue for SPARK: If the postconditions of a subprogram= m >> allow error codes, the caller cannot ignore the error and still prove it= s >> own postconditions (at least for any sort of useful postconditions). Don't forget the two paragraphs above! >> The weak case is about readability. It is a reason why error codes are >> bad, but not quite evil. And it actually is an issue for SPARK: >> >> Source code with well-used exception handlers at the bottom of a block a= re >> often better readable than programs where the error-handlers are >> distributed across the source code, with an error handler after every >> program call returning an error code. > > No, it is not about readability or dangers of not testing the return code= =2E > > The main reason is that exceptions indicate states which usually cannot b= e > handled on the caller's context. (All other applications, e.g. to indicat= e > bugs are illegitimate) > > Whatever the code is, unless indicating "success", some callers cannot do > anything with that and should pass it to their callers and maybe to the > caller's caller and so on. If an exception cannot be handled in the caller's context, the caller=20 cannot satisfy its own postconditions. See above! > The idea of exception is that the caller *cannot continue* when the calle= e > detected an exceptional state. The idea of statically proven postconditions with error codes is to force= =20 the caller to return its own exception code. > Since the callee shall not know its callers, which is one of the major > software design principles, there is no way how return code could be a > substitute to exception. Hu?????? That does not make any sense to me!!! Here is some code with exceptions: End_Error, Data_Error, Mode_Error, Layout_Error: exception; procedure Do_Something(Filename: String); -- may raise any of the above exceptions Here is the same code with error codes substituting the exceptions: type Errors is (None, End_Error, Data_Error, Mode_Error, Layout_Error); procedure Do_Something(Filename: String; Error: out Errors); The only thing that is not possible is for a caller to ignore or re-raise= =20 an exception. It must check the error codes of its callees and, in the=20 exceptional case, return its own error code. This is not necessarily a disadvantage for error codes! One thing that is frightening about exceptions is that by not handling=20 locally declared exceptions, some global caller's caller cannot handle=20 that specific exception at all -- it can only use *the* *same* catch-all when others =3D> ...; exception handler for all such exceptions. For error codes, on the other=20 hand, the Ada type system ensures that the caller will always know the=20 callee's exception codes. > Another reason is distributed overhead of testing return codes. Modern > compilers and processors have zero exception overhead when no exception > raised. Exceptions, when used properly, are rare, thus programs using > exceptions could be far more efficient. I doubt this makes any observable difference. The legitimate examples for= =20 exceptions that "signal things that cannot be known at compile time" (as=20 Randy wrote) are usually related to input-output operations. Your machine= =20 is so much faster than such external devices that the overhead for a=20 comparison like "if Error_Code /=3D None" would be negligible. Stefan -------- I love the taste of Cryptanalysis in the morning! -------= - www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-luck= s ----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universit=E4t Weimar, Germany-= --- --8323329-1294552761-1440144366=:23241--