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!wns14feed!worldnet.att.net!208.49.83.154!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: Sat, 20 Jan 2007 11:08:42 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:bAaOV/X3z7Ejcft5Lt8vs2wMMpI= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: af6bc45b23e8d759e00d427590 Xref: g2news2.google.com comp.lang.ada:8364 Date: 2007-01-20T11:08:42-05:00 List-Id: Robert A Duff writes: > Stephen Leake writes: > >> I don't follow. Strings are perfectly valid Ada constructs. Why does >> the code to build the string not feel like Ada to you? > > Building strings is fine. Requiring clients to parse them is evil -- > not type safe. Well, "evil" is a judgement (more below). I agree with "not type safe". > The whole point of exceptions is to separate the detection of potential > errors from the handing of them. Well, that's one view. I don't think that's consistent with the current definition of exceptions in Ada. Which is the point of this thread, I guess :). I think the point of exceptions is non-local transfer of control. A low-level routine encounters a problem, that only some routine several layers up is prepared to handle. Rather than passing status thru each layer, you raise an exception, and jump directly to the right place. > A well-designed exception mechanism would allow the client to make > these decisions: > > Is this condition really an error? > > If so, is it a recoverable error, or is it a plain old bug? > > If recoverable, what should I do? That's a reasonable list. My current project does make those decisions, based solely on the exception names. I have not thought very hard about whether it could make better decisions if it had more information. So far, I'm happy with the decisions it is making. > If it's a bug, should I print out useful information? Useful to the > user, or useful to the programmer who wants to fix the bug (or both)? That's an upfront design decision, not a run-time decision. > (Example: if the gnat front end detects a bug in itself, it prints > out the line number it was processing at the time, which is useful > to the user who wants to find a workaround.) Right. And that is a design choice was made by AdaCore, not a run-time choice of the compiler; the compiler does not do that for some bugs, but something else for other bugs. > Granularity of handling -- do I want to handle all I/O errors, > or just the "disk full" error? I think you are hinting that you want classes of exceptions, rather than single names. I agree I would find that useful sometimes. In Ada, we get this only by including each name in an exception choice list. Ugly, but functional. > Etc. That's always a fun word. I doubt that the things I extrapolate here are the same ones you do :). > Constructing a string at the "raise" point is wrong because it presumes > that the client wants to print a string That is the overall design of my application, so it is correct in this case. Designing a library that will be used by unknown future applications, yet still returns truly useful information in error cases, is a very hard problem. > and exit, Not in my application. Some exception names indicate fatal bugs that require exit, others indicate a user error that require "stop, let the user change something, try again". Again, that is the overall design of my program. > and it presumes the format of that string. No, since the string is never parsed by the program, only by the user (a much more flexible parser :). Hmm. I do have some formatting conventions; if a file is involved, I format the file name, line number, and column information using the Gnu standard, so Emacs parses it easily. VMS had a binary file format for error messages from the compiler, that LSE could interpret. Other programs could output that same format; it was a VMS standard. That is an example of structured information, vs the Gnu standard of formatted strings. It appears that the market has voted for formatted strings in this case :). > If that were OK, then why have exceptions -- why not make the code > that detects the error print a string and exit? See above. In addition, in the case of fatal errors, there is cleanup work to be done; shutdown external sockets, terminate other tasks. I suppose you could leave all that to the operating system, but I choose not to. I get better error messages this way, so I have a better chance of fixing the problem. > Suppose we want to print error messages in French. If the "raise" point > constructs a message in English, the client can't make that decision. Yes, that is what Internationalization libraries attempt to accomplish. I have not investigated doing that in depth (it is _not_ a requirement for my current project). What little I have heard about this sounds like it is impossible to get truly right; at best you must impose very strict rules on formatting of all messages, and use some sort of codes rather than any natural language when constructing the messages. That is a case where the error information is structured, rather than a flat string. So doing that with exceptions in Ada may be difficult. On the other hand, I think the Gnu internationalization libraries use formatted strings for this. Randy often says "sometimes you have to go outside the language" in order to get something useful done. It may be that error handling is a case where it is appropriate to forgo type safety, because of all the other practical issues that come up. Let's remember that type safety is a means to writing programs more efficiently, not an end in itself. If it gets in the way of writing programs efficiently in some limited area, it should be relaxed in that area. That seems to be the case here. -- -- Stephe