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,699cc914522aa7c4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!uns-out.usenetserver.com!news.usenetserver.com!pc02.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Structured exception information References: <1169819196.5976.57.camel@localhost.localdomain> <1170010221.6748.194.camel@localhost.localdomain> <1170269889.28280.69.camel@localhost> From: Stephen Leake Date: Thu, 01 Feb 2007 07:20:50 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:fQbvNQdliZcb3hlwcmj+pNbzUMQ= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 27d4345c1db26759e00d408878 Xref: g2news2.google.com comp.lang.ada:8814 Date: 2007-02-01T07:20:50-05:00 List-Id: Georg Bauhaus writes: > On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote: > >> 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! Ok, so the answer to my question is "no". There certainly was a problem, but it appears that structured exceptions were not accepted as a solution. On the other hand, neither was programmer education, so apparently we are both wrong :). >> 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. Yes, I have said that designing exceptions for libraries intended to be used in a wide variety of systems is hard. In that case, it might be useful for the library to define a structured exception type. But it might be even better to provide status instead of exceptions. >> > 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. So I'm talking about having control over the _entire_ system, and you are talking about third party libraries. That is different. -- -- Stephe