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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!208.49.83.146.MISMATCH!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: From: Stephen Leake Date: Tue, 23 Jan 2007 04:46:22 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:zlrYnI0HT+LoIuBu7920xf8dn58= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 2f62245b5d974759e00d421142 Xref: g2news2.google.com comp.lang.ada:8413 Date: 2007-01-23T04:46:22-05:00 List-Id: Maciej Sobczak writes: > 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. Those error messages are defined in the HTTP standard, not by the application! This business of passing back an error code instead of a string is all heritage from C. C _can't_ pass back a string, let alone an exception, so it relies on the horrible kludge of 'errno' and 'perror'. Ada can, and should, do better. > 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. That way, it can be used in a program that is not otherwize internationalized. 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. But I think that is a poor component, compared to one that includes internationalization. >> What will the exception handler do with the result of the lookup? > > Display it. The point is that the HTTP component has no idea where the > display is, not to mention the current language - these are managed by > higher levels of the software. 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? > You can argue that return code instead of exception might do the job > and that's true - but then we are back to the discussion of return > codes vs. exceptions, which is a paradigm issue Yes, exactly. > - which should be independent on the technical abilities of each > solution. 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. Apparently it could be done with relatively little cost in Ada 2015, so we should push for it. > otherwise designers cannot make free paradigm choices. In general that is a Good Thing. -- -- Stephe