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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,61e9062c1f23b9d5 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps90.POSTED!023a3d7c!not-for-mail Sender: blaak@METROID Newsgroups: comp.lang.ada Subject: Re: contracted exceptions References: <1181165630.012508.55290@i38g2000prf.googlegroups.com> <19fxsxv1god43$.1pqq8vgfu2itn$.dlg@40tude.net> <1it2vtizha2fi$.jxnoaxmm9sop$.dlg@40tude.net> <12vqux55uf5rn.1u5enj1mh0ubk$.dlg@40tude.net> <3lowwfm48x76$.18vzi5t6t4mf9.dlg@40tude.net> From: Ray Blaak Message-ID: Organization: The Transcend User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Jun 2007 17:06:19 GMT NNTP-Posting-Host: 208.66.252.228 X-Trace: edtnps90 1181581579 208.66.252.228 (Mon, 11 Jun 2007 11:06:19 MDT) NNTP-Posting-Date: Mon, 11 Jun 2007 11:06:19 MDT Xref: g2news1.google.com comp.lang.ada:16160 Date: 2007-06-11T17:06:19+00:00 List-Id: "Dmitry A. Kazakov" writes: > On Mon, 11 Jun 2007 04:13:52 GMT, Ray Blaak wrote: > > > "Dmitry A. Kazakov" writes: > > >> Right, this is why continuation in any form, including raising exceptions, > >> is unsafe. There must be an independent program [a judge] to handle the > >> case. > > > > What to do depends on the program in question. A quiet quick death would be > > the worst thing to do for a common office-like desktop application. > > Surely the best thing is to corrupt all open documents and ones in reach, > accompanied by system resources leakage. The second good is to pop up a > modal panic message dialog in an endless loop. That would show the customer > that guys really worked hard on fault tolerance... Ah, no. With decent exception handling (i.e. a sound central policy) in practice apps tend to be able to survive gracefully. The guys really should be working hard of fault tolerance. Also, the possibility of corruption and leaks is only a possibility, and trying to survive at least allows the user the possibility of the salvaging of what they were doing. > > > Do to absolutely nothing, leaving it up to some external judge/debugger > > program, is in practice completely ridiculous. > > You took it out of context, which was: continuation is unsafe (=> > impossible). I know the context, starting with "assertions should not cause unplanned exceptions", and followed by "use the debugger to stop on such failures". I can see this as a correct theoretical approach, but the problem is that both items are not workable in practice. When an assertion is violated, control flow *must* be aborted, since to continue is dangerous. Exceptions accomplish this. But at the same time it is severely inconvenient to the user to just crash the entire application. It is quite common that apps can set themselves to a reasonably known state, and from there have some survivable work be saved. If nothing else, one can try to save state to alternatve recovery files to minimize chances of corruption of existing files. This is still a controlled exit, better than simply stopping. To be more clear: assertions *must* cause unplanned exceptions, and apps out in the field cannot rely on a debugger. Continuation is unsafe, but just stopping is not helpful either. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.