Re: new revision ada

[James Rogers <jimmaureenrogers@att.net>]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in 
news:cb927q$332$1@a1-hrz.uni-duisburg.de:

> Ada has facilities to implement "trying-out programming". If one
> (logical) thread of control fails, and it is important to
> collect information about why it failed and in what program
> state, than save the relevant pieces of the program state
> using the executable statements of a local exception
> handler for example.
> You can store the information somewhere for lookup, and
> use Ada's exceptions, or task communication, or plain
> returned values to inform the caller of the failure or
> success. The caller can use this information to retrieve
> what has been stored for lookup.

Your solution detaches the information from the notification.
This detachment causes problems, which are compounded by
concurrency. If two exceptions are raised in a program and
their state information is stored in some buffer such as
a protected object, how will a handler determine which state
belongs to which exception occurrence?

The state information must be directly associated with the
exception occurrence. In Java this is done be creating an
exception object. References to that object are passed
up through the call stack until the exception is handled.
I believe the same concept is used in C++ exceptions.

Ada has a somewhat different view of exceptions. All exceptions
are the same type, and are identified by name. Ada 95 added the
ability to define exception information in a limited length
string. That string is intimately associated with an exception
occurrence. I am proposing that we provide a second kind of
exception information using a variable-width string that
encodes data in XML. XML is capable of encoding any kind of
data including very complex data structures. This new form
of exception information will allow complex exception state
data to be reliably communicated with an exception 
occurrence.

Jim Rogers