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!news1.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!solnet.ch!solnet.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Structured exception information Date: Tue, 23 Jan 2007 15:18:11 +0100 Organization: CERN News Message-ID: References: NNTP-Posting-Host: abpc10883.cern.ch Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: cernne03.cern.ch 1169561892 5506 137.138.37.241 (23 Jan 2007 14:18:12 GMT) X-Complaints-To: news@@cern.ch NNTP-Posting-Date: Tue, 23 Jan 2007 14:18:12 +0000 (UTC) User-Agent: Thunderbird 1.5.0.9 (X11/20061220) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:8420 Date: 2007-01-23T15:18:11+01:00 List-Id: Stephen Leake wrote: >> A real example is a HTTP component that reports error code with value >> 404 and the GUI leyer that looks up the dictionary of messages for >> currently selected language to resolve it to whatever is appropriate >> for display. > > I don't buy it. Any HTTP component that I build will provide the > dictionary of HTTP error messages. Surely it will also contain Polish versions of these messages, right? > Those error messages are defined in > the HTTP standard, not by the application! HTTP standard defines the *meaning* of errors, not their literal text. Localized browsers display messages in local language. > This business of passing back an error code instead of a string is all > heritage from C. Yes. > C _can't_ pass back a string Sure it can. > let alone an exception, > so it relies on the horrible kludge of 'errno' and 'perror'. errno and perror is a kludge, but not inherent for C. There are lots of interfaces (POSIX threads, for example) designed for C that work without global errno. > Ada can, > and should, do better. Yes. Ada should allow structured exception information, as any other high-level language does. >> The HTTP network component should not be aware about the >> multilanguage abilities of the browser. > > Ah, internationalization of error messages. Again, I think the HTTP > component itself needs to be internationalized to make that work > properly, so it is simpler for the HTTP component to put the error > message string in the exception. No. I've been involved in an application for the Belgian market, where there is more than one official language. It was an application for the call center, where operators needed a possibility to switch the display language at *run time*, depending on the preferences of the client calling them, so that the operator need not be a simultaneous translator. This means dynamic dictionary switching. Can your HTTP component do this? I mean - have you *foreseen* an appropriate API for switching the dictionary between French and Flemish? I guess no. Low-level components should *never* be involved in user-interface tasks like message composition. They should provide *information*, but not *messages*. Ada got it wrong by focusing on the latter in exception handling. > Hmm. I guess an HTTP component that did not want to be bothered with > internationalization could just return error codes, and let the client > deal with internationalization. Bingo. > But I think that is a poor component, > compared to one that includes internationalization. No, it's a perfect component that can be reused in the environment that you didn't even think of when developing it. Separation of concerns. > I don't see how proper internationalization can be done if low-level > components must be unaware of it. As I understand it, there is an OS > call to get the locale; any component that does HTTP is making other > OS calls, so why can't it make that one? Why doesn't it display the message? Why stop at message composition? >> Exceptions should not be any less capable than return >> values are, > > Well, that's a very strong statement. It is certainly a plausible > request of language designers, but we are arguing about whether it is > truly worth the cost, so you can't take that as a starting point. Nobody in this discussion explained why the cost would be prohibitive. On the contrary, examples of languages that do this abound. > Apparently it could be done with relatively little cost in Ada > 2015, so we should push for it. What about Ada's competitiveness till that time? ;-) >> otherwise designers cannot make free paradigm choices. > > In general that is a Good Thing. I don't agree. Not in general. By "free paradigm choice" I mean the choice that is not imposed by implementation constraints. In particular, the choice between exception and return code should not be based on their different type-safety abilities. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/