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,699cc914522aa7c4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Structured exception information From: Georg Bauhaus In-Reply-To: References: <1169819196.5976.57.camel@localhost.localdomain> <1170010221.6748.194.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1170269889.28280.69.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Date: Wed, 31 Jan 2007 19:58:10 +0100 NNTP-Posting-Date: 31 Jan 2007 19:57:55 CET NNTP-Posting-Host: 8bae16ad.newsspool4.arcor-online.net X-Trace: DXC=TPHW81ljUgcJ00P1S40fZg4IUK On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote: > Georg Bauhaus writes: > Based on other examples of whole manuals written by someone other than > the programmers, I don't think that approach will produce good error > messages. Yes, I should have said that I meant the set of all people involved in exception raising and exception handling in the broadest sense of the term. > Have you worked on a real system where this approach was used, and was > in fact better than having the programmers write the error messages? I worked on a system involving 3 companies where one style of exception handling was to be silent about them (empty handlers). Another style was to write a few words that could be understood by the programmer who wrote the handler because he knew the context. These were (are, I think the programs are still up and running) communicating programs, no source code was exchanged. But when the exceptions were reported as strings into some log some of us on all sides were out of luck. Strings are too easy to write. People didn't give them enough attention, and they didn't create exception types either even when this was possible (in Java). And you don't ask for education across company borders if there is a hierarchy. Let alone speak of education! > The system design says exception handlers only have to add > information, never subtract it. Adding information is good, and the advice also needs to mention that exceptions raised *do* have to provide some information :-) > So why not > > create or extend a type for the information and pass objects > > of the type, not formatted strings? > > "Why not"? Because it's easier not to! That is the topic of this > thread. I'm not so sure what is easier to do, write a good exception message or build up an exception object containing the necessary information about what happened. It seems easier to just write an exception message string. Easy programming. But once it is written, the information is as inflexibly coded as can be: You need parsing if you have to extract it. I need to extract it if and when I cannot change what a 3rd party library is reporting. There just is no "education" or telling them what they should write in exception messages. > > In summary, then, I would prefer the separation of typed exception > > data and exception message strings. The first is far more flexible > > It is far _less_ flexible! that is the point. Any pre-defined type > structure is (by definition!) less flexible than a string. I can put > _anything_ in a string; Certainly _you_ can place anything inside an exception message string. (To say a few absurd things, for example a Tcl program. No problem. I could even suggest that we use Storage_Element_Array instead of String for the message as this helps preserving memory layouts... :) As a user of your exception message I get something that is carved in, well, a String. As a user of an exception object of an exception type, I'll have the necessary information at my disposal (hopefully). For me then this is more flexible and easier than parsing message strings. > Except for internationalization support, which can be done > with strings as well. Uhhhm. Anything can be done with strings, as Tcl is demonstrating, but why do we use Ada where is can be done better using object of type. A type for internationalized messages is easy to spot in a program and can be arranged for Ada coverage rules. So you get builtin language checks. If you use just strings, it will work, but you have to use another language processor for scanning message strings reliably. This may work in practice, with proper discipline and heavy scanning, but I think it works around a better solution, one that makes use of the Ada type system.