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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,52fd60a337c05842 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-15 15:04:07 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: ada paper critic Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Sat, 15 Jun 2002 22:03:34 GMT References: <3D095F70.8090001@telepath.com> <3D0A3B59.4A4B9E04@acm.org> NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:26042 Date: 2002-06-15T22:03:34+00:00 List-Id: Jeffrey Carter writes: > This seems to be an incomplete sentence. If I interpret it correctly, > the Ada intent is that the information be carried primarily by the > exception name. You should not be using a single exception and > differentiating between logical exceptions by the information attached > to that exception. The problem with this view is that it forces the designer of an abstraction to decide on the granularity of exception handling, when this decision rightly belongs in the hands of the person designing the *handler*. In fact, different handlers have different requirements: e.g., one handler might want to handle all I/O errors, whereas another one might want to handle disk_full_error specially. If the designer of the abstraction decided to lump all I/O errors under one exception name, then the fine-grained handler is impossible to write. On the other hand, if the designer of the abstraction defined many exceptions for different kinds of I/O errors, then the coarse-grained handler has to mention them all, which is overly verbose, and unmaintainable, because there might be a new kind of I/O error invented tomorrow. So the designer of the abstraction is forced into a poor design for *some* possible clients. This is not good for reusability. In many other languages, this problem does not occur, because exceptions are defined hierarchically. > Also, exceptions should only be used for exceptional situations, so this > does not impact normal processing at all. I don't see how that's relevant. A bug in exception handling is a bug, even though exceptions occur only rarely. (In fact, *all* bugs are rare -- if the thing crashes within seconds most of the time you run it, the programmer will notice it and fix it.) - Bob