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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.43.56.134 with SMTP id wc6mr3367363icb.17.1402069623367; Fri, 06 Jun 2014 08:47:03 -0700 (PDT) X-Received: by 10.182.165.36 with SMTP id yv4mr27188obb.18.1402069623077; Fri, 06 Jun 2014 08:47:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h18no951288igc.0!news-out.google.com!qf4ni19591igc.0!nntp.google.com!h18no951277igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 6 Jun 2014 08:47:02 -0700 (PDT) In-Reply-To: <1l2x0kuk3kxqx$.1owim8xhlww7x.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: <5365d3f0-43cc-47ef-989c-d47992c84c9f@googlegroups.com> <1l2x0kuk3kxqx$.1owim8xhlww7x.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <60fda787-b248-4355-a386-6463c093925f@googlegroups.com> Subject: Re: OT: A bit of Sudoku From: Adam Beneschan Injection-Date: Fri, 06 Jun 2014 15:47:03 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:20167 Date: 2014-06-06T08:47:02-07:00 List-Id: On Friday, June 6, 2014 12:51:47 AM UTC-7, Dmitry A. Kazakov wrote: > > Otherwise, someone could look at a subprogram that is called in between= , > > and never guess that the subprogram might not complete normally (A call= s > > B, B calls C, C raises an exception that gets passed over B's head back= to > > A; a programmer trying to read B might not suspect that B may not compl= ete > > in a non-error situation.) In other words, keep such usages as localiz= ed > > as possible. >=20 > Rather, let Ada 2X formalize exception contracts and leave checking the > contracts to the compiler. >=20 > The scenario you described is the valid and very useful use case of > exceptions. The reason is that, likely, C and B could not handle the stat= e > when the exception was raised and propagated because in order to be able = to > handle it, they must be redesigned completely. They must have the > information hidden from them for very good reason, affect program states > possibly unrelated to them etc. I.e. it would make the design tightly > coupled and fragile. The idea of exception is postponing handling of some > [exceptional] states up to a context where handling were possible, e.g. i= n > A. That context can be and usually is totally unknown to the designer of > the code raising the exception. I'm not sure we're on the same page. What you're describing sounds more li= ke the "normal" use case for exceptions, as I understand it (i.e. for "exce= ptional" conditions); but I thought the discussion was about something diff= erent, namely using exceptions as sort of a stack-unwinding "goto". Even w= ith an explicit contract, it still seems like using exceptions in this way,= for non-exceptional situations, is going to impair readability if its use = isn't kept within a small, local area of the source. This is just my insti= nct, though, and I'm finding it difficult to explain why. =20 -- Adam