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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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/31 Message-ID: <8c139a$onc$1@nntp9.atl.mindspring.net>#1/1 X-Deja-AN: 604606772 References: <89rlvr$gn9$1@nntp3.atl.mindspring.net> <38D8A607.F61F0FFF@mail.com> <8brm79$jm3$1@slb6.atl.mindspring.net> <8brs96$ikp$1@nnrp1.deja.com> Organization: MindSpring Enterprises X-Server-Date: 31 Mar 2000 02:41:46 GMT Newsgroups: comp.lang.ada Date: 2000-03-31T02:41:46+00:00 List-Id: In article <8brs96$ikp$1@nnrp1.deja.com>, Robert Dewar wrote: >In article <8brm79$jm3$1@slb6.atl.mindspring.net>, > Richard D Riehle wrote: >> 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. > >Well I am not quite sure what the disagreement is, but let >me make a couple of comments on the above code. You and I have had a discussion about this and we see its value for applications a little differently, as reflected in your note, below. >It is highly implementation dependent, on some implementations >it may give a useful symbolic traceback, on another, no output >at all, and on a third, may generate a complete core dump. The >output is "implementation defined", which means you know >absolutely nothing about what the above code does from a >portable point of view. It is certainly implementation dependent. It is also not very useful for for what Joyce Tokar calls, "deeply embedded" software since we do not want to be passing strings all over the place. That being said, if Exceptions.Exception_Information does return useful information for a given compiler when used in something such as a command and control application, this could be a nice feature of the implementation. >On a given compiler it may do something useful to you, but you >have to examine any such logging code wrt the implementation >you are using, and adjust the code accordingly. But in practice >most Ada 83 implementations provided facilities like this in >any case (actually many Ada 83 implementations provided much >more extensive capabilities, and the Ada 95 facilities are not >sufficient, we have had to add quite a bit to GNAT here, see >for example, GNAT.Exceptions. Certainly one has the issue of implementation dependency. However, I am not sure I like the idea of parameterizing the exception itself. I do like the Ada 95 addition of, optionally, adding an exception occurrence for certain exceptions. Also, we can provide a parameter in the form of a message for given exceptions. That allows us to call the Exception_Message function where this is deemed useful. That feature is not implementation dependent since we raise the exception with a clear message. A when others becomes problematic. That is one place where the exception occurrence becomes important. Of course we can either Raise a new exception at the place of a _when others_ or label it with an exception occurrence. In either case, we have preserved the efficiency of the exception model while allowing some kind of parameter or access to other useful information. >Also, you hope that compilers have extended capabilities like >dumping the results of an exception EVEN if there are dependent >tasks that prevent propagation. Or dump exceptions that >otherwise terminate tasks silently. Well, yes, that would be nice. On the other hand, if we can target our exception messages with message parameters, these can be quite useful as part of the overall design. Also, the string message could be designed to permit conversion to some other data type using the features of Ada.Text_IO. This is up to the designer, but it does imply a fairly high level of flexibility when one really needs this sort of thing. In this case, there is no dependency on the underlying implementation. We get the general capability of the parameterized exception when we need it. I think the Ada.Exceptions package is greatly underrated by a lot of people. As mentioned above, it is not appropriate for every kind of system, but is quite useful when one applies some creativity to its usages. Richard Riehle