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 X-Received: by 10.66.230.165 with SMTP id sz5mr8570516pac.33.1403796151336; Thu, 26 Jun 2014 08:22:31 -0700 (PDT) X-Received: by 10.182.196.34 with SMTP id ij2mr23327obc.24.1403796151151; Thu, 26 Jun 2014 08:22:31 -0700 (PDT) Path: border2.nntp.dca.giganews.com!nntp.giganews.com!uq10no11853689igb.0!news-out.google.com!bp9ni4igb.0!nntp.google.com!uq10no11853678igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 26 Jun 2014 08:22:30 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <39232f1d-1046-4dc4-b680-ed53830667ed@googlegroups.com> Subject: Re: Help understanding the benefits of Ada's exception model From: "Dan'l Miller" Injection-Date: Thu, 26 Jun 2014 15:22:31 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:187258 Date: 2014-06-26T08:22:30-07:00 List-Id: On Thursday, June 26, 2014 9:28:19 AM UTC-5, Patrick wrote: > Sorry for answering my own post. I think I have not used the terms unchec= ked exception and check > exceptions properly. Better terms would be handling exceptions and handl= ing error codes. Exceptions in modern Ada (since the addition of Ada.Finalization.Controlled= types in Ada1995) are extraordinarily valuable in accomplishing reclamatio= n of resources upon unwinding the stack by invoking object O's procedure Fi= nalize( in out O), which allows you to release resources properly (e.g., f= ree DRAM; increment a semaphore; close a file; abort a transaction in a dat= abase; cancel an operation in an FPGA or ASIC). Yes, you analyze a leaf-to= -root walk of every call-tree in entirely-error-code-based code, but you wi= ll get fatigued and miss at least one branch where some one or more resourc= es should have been released upon the error, but were not. Note that invok= ing Finalize is an implicit operation, without any overt source code (other= than some END somewhere that was there anyway). This is part of what C++ = has since the late 1990s calls RAII: resource allocation is initialization= , or what we C++ old-timers back in the late 1980s called "all allocations = in constructors; all deallocations in destructors" to achieve exception-saf= ety. Ada1995's Ada.Finalization.Controlled wisely brings analogues of C++ = constructors and destructors to Ada. (Btw, thank you very much for that, S= . Tucker Taft & Co!) Conversely, unlike exception safety, note that there is no cross-cutting au= tomated assistance for error-code safety, without an extraordinary amount o= f temporal logic, program slicing, and term rewriting to detect as a post-m= ortem where the resource-to-delete's lifetime has already previously ended.= This post-mortem analysis occurs somewhat later than it does in exception= s: the post-mortem for error codes is correlated vis a vis some (in effect= entirely unrelated) integer error code conditional test on some branch not= on the "happy path" of the code, whereas the analogous invocation of Final= ize( in out O) occurred after the raise exception but before the handler, i= .e., during the implicit unwinding of the call-stack between the instant of= raising the exception and the instant of invoking the exception handler. In general, if the error requires clean-up of resources (and especially if = those resources were not allocated locally, but rather allocated hither & y= on throughout the codebase), then exception-safe RAII-style deallocations t= riggered by raising an exception are clearly the best practice. Conversely= , if no resources need to be deallocated or if all resources were allocated= locally (e.g., same function; same procedure; encapsulated in same object)= or if the event was not truly an error (e.g., naturally reaching the end o= f file, as was eventually expected anyway), then returning integer result c= odes may be the best practice. Note the change of wording there: proper u= sage emphasizes result codes stating mere (non-error) outcomes, whereas exc= eptions emphasize errors.