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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6327f05d4989a68d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.72.199 with SMTP id n7mr15871751qaj.5.1356618543065; Thu, 27 Dec 2012 06:29:03 -0800 (PST) Received: by 10.49.39.99 with SMTP id o3mr4509959qek.14.1356618543049; Thu, 27 Dec 2012 06:29:03 -0800 (PST) Path: k2ni3151qap.0!nntp.google.com!ee4no2560565qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 27 Dec 2012 06:29:02 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=206.53.78.59; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 206.53.78.59 References: <7wrdmbre6jw9.qww9l0uzj6mg.dlg@40tude.net> <14oqoq06zhlu2.tcasif3hdyhw.dlg@40tude.net> <1drh1q1ln2dfh$.a9hwlg01fjfy.dlg@40tude.net> <50d6365d$0$6577$9b4e6d93@newsspool3.arcor-online.net> <1pbg79bz92j3t$.sz41zduivjfp.dlg@40tude.net> <4c101d74-c8cb-45a6-82d4-91923bb950b0@googlegroups.com> <87sj6tre9s.fsf@mid.deneb.enyo.de> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <895c9eb7-03f8-4b0c-96b4-3dbd7a315ccd@googlegroups.com> Subject: Re: Press Release - Ada 2012 Language Standard Approved by ISO From: sbelmont700@gmail.com Injection-Date: Thu, 27 Dec 2012 14:29:03 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-12-27T06:29:02-08:00 List-Id: On Wednesday, December 26, 2012 8:47:29 PM UTC-5, Randy Brukardt wrote: > As I mentioned last week, exceptions are used for two purposes: one > is "checks", which should never fail at all.... The other kind is an > exceptional termination, like End_Error=20 While I agree 100% with the first part, I remain extremely skeptical about = the second. I've yet to be convinced of a case where its necessary/prefera= ble/best-structured to propogate an exception out to be handled by the clie= nt instead of making the client check it beforehand. You show me a subprog= ram that raises End_Error and I'll show you a subprogram that needs a preco= ndition "not At_End". If you are rasising "File_Not_Found" then you need a= precondition of "File_Exists". The onus is on the interface to provide th= e necessary information to the client to ensure exceptions do not happen in= the first place, and the onus is on the client to make sure they are met *= before* the call, not to swoop in afterwards to clean up the mess. If you = can handle it (that is, correct the actual problem and continue as before),= you can prevent it. -sb