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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,820de86ed0dafb8a X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Help Me Please :) Date: 2000/03/29 Message-ID: <8brm79$jm3$1@slb6.atl.mindspring.net> X-Deja-AN: 603663937 References: <89rlvr$gn9$1@nntp3.atl.mindspring.net> <38D8A607.F61F0FFF@mail.com> Organization: MindSpring Enterprises X-Server-Date: 29 Mar 2000 01:28:09 GMT Newsgroups: comp.lang.ada Date: 2000-03-29T01:28:09+00:00 List-Id: In article , Robert A Duff wrote: >Mats Weber writes: > >> I think the designers of Modula-3 got it just right. You can have a look >> at http://www.m3.org/ > >I beg to differ, again. ;-) > >I see several problems with Modula-3's exception mechanism, some of >which are shared by Ada. (My knowledge of the language comes from >Harbison's book, "Modula-3". I've never written a Modula-3 program.) I agree with you about the Modula-3 problems. Do not entirely agree with you about Ada. There could be some benefits to the paramterized exception, but these would be small and are already adequately covered by the features of Ada.Exceptions. Dr. Dewar and I do not usually agree on the benefits of the functions in Ada.Exceptions, but we do agree that exceptions are overused in most applications. >There's no hierarchy of exceptions. This means that the designer of >some code that raises exceptions must decide on the granularity of >exception handling; it would be better for the handler to make that >decision. For example, one handler might want to handle all "I/O >errors", whereas another handler might want to handle just "disk-full >error". Making exceptions first-class objects (which they are not, in >Ada and Modula-3) would solve this problem, at no cost in language >complexity. There would certainly be an increase in complexity in the creation of hierarchical exceptions. >An exception takes just one parameter. Why not two or three or however >many I like? Again, making exceptions extensible object types would >solve the problem. And what would be the parameter type(s)? Are you suggesting an exception defined with parameters in the same way one defines subprograms? That would seem to increase complexity of both the compiler design and the resulting applications. It is an increase in complexity that seems unnecessary under any but the most unusual circumstances. >The behavior in the presense of "checked run-time errors" (things like >divide by zero, arithmetic overflow, array index out of bounds) is not >defined by the language. So an array index out of bounds might raise >Array_Index_Error on one implementation, and Constraint_Error on another >implementation, and simply stop the program dead in its tracks on a >third implementation. I don't like that non-portability. I agree it is useful to track such things. That is why I like the addition of Exception_Occurrence to the language in Ada.Exceptions. when Some_Nasty_Error : Constraint_Error => Error_Manager.Log(Ada.Exceptions. Exception_Information(Some_Nasty_Error)); This is where Dr. Dewar and I differ. I see this feature as important for applications such as command and control systems. He sees it, as of our last discussion of the subject, as less important than I. >(On the other hand, Ada *pretends* that it's OK to raise and handle >Constraint_Error, but if you read RM-11.6, you'll find that's not quite >true -- and I doubt if any Ada programmer other than Tucker Taft >actually *understands* 11.6. So in practise, 11.6 says, "Do not handle >predefined exceptions.") ALRM 11.6 rarely presents a problem to the applications programmer. It behaves according to a set of rules that has no deleterious effect on the underlying application. It is, as I read it, as set of permissions, not a license to destroy source code intent. >The "raises set" of a procedure defines what exceptions it can raise. >The problem is that this rule is checked at run time. Java is closer to >the right solution -- it checks that rule at compile time. However, >Java suffers from the "cry wolf" problem. I think it's possible to >avoid the "cry wolf" problem, and still do most of that checking at >compile time. The entire C-family of languages, especially C++, is somewhat problematic when examining exception handling. This is another of the "devil is in the details" issues. I don't think Java exception handling measures up in those circumstances that Ada does well. Ada is simpler to understand and probably a little more efficient. Also, Java exception handling seems to lead people to depend too much on exception handling when they ought to be writing programs to check conditions instead. Ada 95 has added the 'Valid attribute for such checking and it can be used nicely in circumstances where one might otherwise raise an exception. I am reminded of C.A.R. Hoare's Turing Award Lecture in which he criticized Ada for having exception as part of the language. Now every language has some kind of exception handling. Ada looks downright conservative when compared to more recent offerings for exception management. >There is no re-raise statement (spelled "raise;" in Ada), so a "when >others" handler (Ada spelling again) can't propagate the same exception. >You can't raise the same exception occurrence, because the thing >available in the handler is not the occurrence, but just its parameter, >and then only if you named a particular exception. A Reraise_Occurrence is included in Ada.Exceptions. It is not very difficult to invoke this routine when one declares a limited type of Exception_Occurrence and attaches it to some Exception_ID. In fact, one may save an Exception_Occurrence and raise it again at some other point in the program. >Return and exit statements are defined in terms of raising a RETURN or >EXIT exception. That seems kludgy to me, because exceptions are for >cases where the target of the jump is determined dynamically, whereas >return and exit are jumping to a statically-known place. So it's sort >of overkill. In practical terms, it means that a "when others" will >handle a RETURN or EXIT, and you can't re-raise it, so the return >doesn't actually return, and the exit doesn't actually exit the loop. As mentioned above, it is possible to save and Exception_Occurrence and ReRaise it. As to return types, it is also useful to use a 'Base value for certain return types and check those on return. Of course, you know this feature better than I. You also understand the excellent arguments against doing it this way. >All exceptions must be declared at top level. This solves the >kludginess of Ada, where they can be declared anywhere, but act *as if* >they were declared at top level. But I think there are better solutions >to that problem, based on the "procedure declares what exceptions it can >raise" idea of Modula-3, Java, etc. Agree that exceptions should be declared at a very high ("top") level. This is done quite nicely using child library units where the top level of a hierarchy is the declaration of the exceptions one will use throughout that hierarchy. In this case, they are also in scope for any clients. >There's nothing like Eiffel's preconditions, postconditions, and >invariants, which tie exceptions to the conditions that cause them. In >Modula-3, you can say "this thing might raise Stack_Full", whereas in >Eiffel you can say, "this thing will raise Stack_Full if Full(S) is >True." No argument with your ideas about Eiffel. I would like to have some model for pre-, post-, and invariants in the next version of Ada. At that time, it would be appropriate to revisit some of the capabilities of exception handling. That being said, as you know, most safety-critical software will avoid exceptions entirely. Another reason why the new 'Valid attribute is becoming useful. >So, I think CLOS, Clu, and Eiffel (and to some small extent, C++) all >have better ideas about exceptions than Modula-3 (or Ada). Agree about Eiffel. Not sure about CLOS or Clu. Definitely disagree about C++. The exception handling in C++ can only be described as scary. Richard Riehle