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!border1.nntp.dca.giganews.com!nntp.giganews.com!elnk-atl-nf1!newsfeed.earthlink.net!out01a.usenetserver.com!news.usenetserver.com!in01.usenetserver.com!news.usenetserver.com!in03.usenetserver.com!news.usenetserver.com!pc03.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> From: Stephen Leake Date: Mon, 29 Jan 2007 21:15:47 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:PUKmnoPElj1VcQrQP2qiMgfGP0Y= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: d22ce45beaa55759e00d430124 Xref: g2news2.google.com comp.lang.ada:8699 Date: 2007-01-29T21:15:47-05:00 List-Id: Georg Bauhaus writes: > On Sat, 2007-01-27 at 13:17 -0500, Stephen Leake wrote: > >> In addition, you have ignored the problem that each version of >> Write_Output for different hardware will need need a corresponding >> version of the exception type; more work. > > Versions of Write_Output for different hardware might also > need a different string passed with the exception? There is one Write_Output for each hardware type, so that's what happens now. > For example in order to clearly indicate which hardware is > reporting. I'm not so sure a different type is needed for every > variation in hardware. A serial number component might do, if the > hardware is sufficiently similar. Yes, if there are 5 Analog_Output cards in the system, each one has a name or number, and that is included in the exception string. > Why is it better to have this setup that seems more complicated? > (Isn't it strange to hear an Ada programmer ask why it is > better to not just lump information into a string? :-) :-) > Now who best writes the messages (1), what should be included (2), > and where in the program should they be formatted(3)? > > (1) Programmers tend to leave out necessary context information > judging by the brief shouts of command line tools that have > caused so much anger and Google searches for explanations. > Natural language experts aren't usually available during > development, so it seems an advantage to add another level of > indirection, just provide the information, and delegate the > formulation of messages to the domain experts. Hmm. I agree that some members of my team have not yet learned how to write good error messages. The solution is to educate them :). Or to have someone who is good at it review and fix the messages. 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. 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? > (2) How can a programmer anticipate how the information > "raised" from his/her module is best used elsewhere? Because there is a system design. Without a system design, you cannot do error messages correctly. > E.g., MS recommends not to show stack traces from failing > ASPx programs to end users. Good advice. I have the same policy. > Perhaps show a nice page with some error code and an invitation to > report or come back later. But what can an Ada exception handler do > here if all exception information is already frozen inside a string? > Parse it? There are no stack traces in the messages I've shown. The system design says exception handlers only have to add information, never subtract it. If all programmers follow the system design, there will never be inappropriate information in an exception message. If some programmer doesn't follow the system design, educate them! > (3) As you have explained, SPO sentence construction rules are > not universal. The usual approach is therefore to use sprintf- > like procedure calls for message construction. Yet, whatever the > grammar rules of a natural language might require, the > information available *for* message construction is unchanged > by the fact that it can be turned into a sentence. 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. > 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; I can only put the pre-conceived classes of information in a structure. So when I write the Write_Output for my wizzy new piece of hardware, I will _also_ have to extend the exception class; not worth it. > and accessible for anyone but the lazy programmer who writes the > exception message strings after "with" ;-) "accessible" meaning "easy to change some details of the presentation", yes. But I remain unconvinced that small gain is worth the cost. Except for internationalization support, which can be done with strings as well. -- -- Stephe