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!edtnps82.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> 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: Thu, 07 Jun 2007 21:11:32 GMT NNTP-Posting-Host: 208.66.252.228 X-Trace: edtnps82 1181250692 208.66.252.228 (Thu, 07 Jun 2007 15:11:32 MDT) NNTP-Posting-Date: Thu, 07 Jun 2007 15:11:32 MDT Xref: g2news1.google.com comp.lang.ada:16094 Date: 2007-06-07T21:11:32+00:00 List-Id: Robert A Duff writes: > Ray Blaak writes: > > > "Dmitry A. Kazakov" writes: > >> I would like to see contracted exceptions... > > > > The Java experience shows that compiler checked exception > > specifications don't work. > > I don't quite agree. I'd say the Java experience shows that the exact > rules of Java don't work very well. But that does not imply that the > whole idea can't work well. I think the problem is that one cannot reliably predict in advance which exceptions can propagate. Furthermore this set can change over time as a system is maintained. > you want some way to say "Iterate can raise anything that Action can > raise". The actual parameter passed to Action, I mean. My point is that in general it doesn't matter. What happens when something unexpected is raised anyway? You still have to have a strategy for that. > Well, the compiler isn't doing the forcing, the programmer who defined > the exception is. And you're not forced to handle it; you also have > the choice of declaring it to be propagated. The heavy use of 3rd party libraries in Java programs at least dictates it to the programmer. Sure, the programmer can define better behaviours in their own software. Also, declaring exceptions to be propagated cause internal design artifacts to be propagated to the public specification of the design. A compromise approach I have seen and used myself is to let all possible exceptions propagate freely in the internals of a subsystem, and then at the public edges handle and wrap into the official publically allowable exceptions. Some more modern Java libraries make use of unchecked exceptions. E.g. the org.w3c.dom API has its root DOMException type derived from the unchecked RuntimeException. > > If one observes what actually is needed for exception processing it tends to > > be: > > > > a) abort control flow - the current op cannot proceed. > > b) report the error to the user in a central way (in a popup, via a log, > > whatever), and either exit or wait for the next new input/action. > > True of some programs. But many embedded systems have no use for > popping up or logging. So what do embedded systems tend to do? They cannot simply halt after all. My guess is that they handle known (i.e. expected) errors has best they can, possibly with recovery, but unknown errors simply cause some sort of reset to a known state. This is still a central strategy, no? -- 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.