Re: Help Me Please :)

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <8brs96$ikp$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>In article <8brm79$jm3$1@slb6.atl.mindspring.net>,
>  Richard D Riehle <laoXhai@ix.netcom.com> 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