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!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: Sat, 20 Jan 2007 10:33:40 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:M0nYydiJ/7HoAFmrwQx+Li6aNjA= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: f312745b23657759e00d424535 Xref: g2news2.google.com comp.lang.ada:8363 Date: 2007-01-20T10:33:40-05:00 List-Id: Maciej Sobczak writes: > Again - going down this route, what's wrong with having only strings > in the language? Tcl is a powerful language that is quite successful > with only strings. That's absurd. I said "Strings are the correct type for presenting information to the user". My full system uses strings for that purpose. It uses many other types for other purposes; quaternions for orientation, unbounded arrays for dynamic lists, binary trees for sorted symbol tables, hash tables for fast lookup of symobls, a class hierarchy with abstract operations for models, records with bit-level representation clauses for hardware registers. Etc. >> You have not said _why_ you need to dismantle this information in the >> handler. What, _exactly_, will the handler do with the separate bits? > > Looking up the localized error message in the dictionary based on the > *type-safe* error code that it got from the exception object, > probably? Why would it do that? The original problem was "present this information to the user". Again, I'm asking for a _detailed_, _real_ example! > I expect *type-safe* error code which I can look up in the dictionary. Well, ok, that's a fairly clear requirement. And yes, Ada exceptions cannot include a type-safe error code. But I don't understand _why_ you want to do that in the exception handler. Why didn't the callee look up the error code, and put the string in the exception message? What will the exception handler do with the result of the lookup? > I'm looking forward to see a convincing solution for error code and > the dictionary. You have not defined "dictionary" here. If I assume it just contains strings, and the handler will simply output that string to Standard_Error, then having the callee do the lookup is a perfectly reasonable solution. >>>> As a general matter of user-interface design, I would find that >>>> annoying. As a user of a system, the only thing I want from an error >>>> message is either "how do I fix this myself" or "how do I report this >>>> to the maintenance team". >>> That is a reasonable approach and will work fine most of the time, >> When will it not work? I have never encountered such a case. > > It will not work in those cases where the handler might attempt to > "fix things" and retry the operation that failed instaed of displaying > the "sorry" message. > Consider for example a compuational algorithm that failed to allocate > some memory that was needed for computations. Exception > is raised and goes up to the handler that as a first attempt tries > to flush some in-memory caches or other transient buffers and > restarts the computation with the hope that it can now succeed with > more memory available in the system. There is no need to display > anything to the user and string format has no use here. Even for > this simple case I can imagine that the code in question can include > in the exception object the size of the allocation that failed, so > that the handler can make more optimal decisions as to what should > be flushed. In such a case, I'd expect the size information to > retain the type safety that should be there from the very beginning. Ok, that's a concrete example. Thank you. >> If you look into the details of "structured exception handling" in >> other languages and implementations, they have bugs, and fundamental >> flaws in design. > > Ada does not have this, because it *might* be difficult for > implementers? Not "might be difficult", but "is impossible to get truly right in _all_ cases required by the language". Hmm. "impossible" may be too strong. "we know of no way to do it" is probably closer. As Randy has been saying, now that the rest of Ada has evolved, it may be that we now _could_ find a way to have structured exceptions in the next version of Ada. > Is it better if programmers find it more difficult to write final > programs instead? Yes! Let's be clear. Here are the choices: 1) Define structured exceptions in Ada. We _know_ that _all_ compilers will not meet the standard in some way, and each in different ways. 2) Define only strings for exceptions. Let the programmers use other methods to solve particular problems. In case 1), I will never be able to rely on the exception information, so I will only use strings anyway. >> That is why Ada did not go that way. Ada is _much_ >> more careful about getting the core design right > > It failed in this aspect. Well, you are interpreting "right" to mean "has everything I want"; I meant "is internally consistent, has no unexpected behaviors, has a reasonable implementation approach". >> allowing fully >> robust and safe implementations of _all_ features > > Is there anything in Java or C++ or Python or whatever exception > handling that makes it fundamentally impossible to implement correctly? Yes, which is why none of those implementations fully meets the standard, and each implementation differs from the others, sometimes in subtle ways. >> especially in >> multi-tasking and multi-processing environments. > > Why should I care about multi-tasking and multi-processing > environments when writing single-tasking programs? Well, that is a reasonable point. Ada made the choice to make multi-tasking work right, as part of the language. So you may want to choose another language, if this particular choice make Ada unsuitable for you. > Should I be constrained in my work just because some feature might > be difficult to implement elsewhere? I'd say no, but just in case I > propose an easy solution for everybody: just forbid structured > exceptions in multitasking and distributed environments and allow > them where they will naturally work. BTW - somehow Java exceptions > work fine By "fine" do you mean "i've never had a problem with them" or do you mean "everyone who has studied these issues in depth agrees that the Java implementation will _never_ have a problem"? Those are two very different statements. I prefer a language that uses the second approach. The Java class libraries have lots of deprecated procedures, that "worked fine" when they were first released, but had problems of one sort or another when people tried to use them in unanticipated but clearly reasonable ways. Ada tries very hard to avoid that sort of thing, especially in the core language. >> So if you find yourself fighting Ada to do something, you need to step >> back and think more carefully about _why_ you are doing it that way. >> Ada is telling you it is inherently unsafe. > > Sorry, I don't buy this. I stepped back, thought more carefully and I > haven't seen any solution for looking up error code in a dictionary or > for transmitting size information so that the handler can make optimal > decisions before retrying memory-expensive computations. In Ada, you need to pass back an error code of some type, or the size, not use an exception. That is a valid solution. Using exceptions for this is inherently unsafe. -- -- Stephe