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!news.glorb.com!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: Fri, 19 Jan 2007 14:36:54 +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 1169213814 15993 137.138.37.241 (19 Jan 2007 13:36:54 GMT) X-Complaints-To: news@@cern.ch NNTP-Posting-Date: Fri, 19 Jan 2007 13:36:54 +0000 (UTC) User-Agent: Thunderbird 1.5.0.9 (X11/20061220) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:8325 Date: 2007-01-19T14:36:54+01:00 List-Id: Stephen Leake wrote: >>> Then what's wrong with a string? >> Doesn't feel as type-safe as advertised. > > But you have not given an actual example where a string is not > a type-safe solution to the actual problem at hand. Going this path a bit further, I find it difficult to convince myself that Ada is any better than, say, Perl. :-) >> Sure. That's why there are more JavaScript programmers than Ada programmers. > > I don't follow. Strings are perfectly valid Ada constructs. Why does > the code to build the string not feel like Ada to you? 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. > 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? >> Still, that's not what I expect from Ada. > > Lots of people expect lots of things. And lots of them find these things in other languages. > Sometimes, those expectations > are unreasonable, and should be changed. Sometimes, yes. > That's what I'm trying to > explore here; I think expecting anything other than a string for > exception data is unreasonable. I expect *type-safe* error code which I can look up in the dictionary. > So far, you have presented no case to show I am wrong. I'm looking forward to see a convincing solution for error code and the dictionary. >>> 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. > 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? Is it better if programmers find it more difficult to write final programs instead? > 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. > 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? > especially in > multi-tasking and multi-processing environments. Why should I care about multi-tasking and multi-processing environments when writing single-tasking programs? 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 in a distributed environment, so there is a proof that such thing is possible. > 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. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/