Re: exception scheme in m3na

The use of AtomList.T as the exception parameter provides several things:

1.  Single exception for a wide class of errors makes RAISES clauses less
complex.
2.  Ability to extract specfic exception details via parameter.  In
effect,
the parameter gives you the ability to discriminate between exceptions by
examining the first Atom.T in the list.  This comparison is very fast. 
You
can publish in the interface a list of all Atom.T that can appear as the
first item in the list.  The only drawback at this point is that they have
to be VAR with the understanding that they should be treated as CONST
after
module initialization.
3.  Ability to provide a cascade of exceptions to drill down to the root
cause of a problem.
4.  Ability to provide useful error messages to end users via the encoding
of TEXTs as Atom.Ts.

Regards,
Randy

"Henning Thielemann" <iakd0@[EMAIL PROTECTED]
> wrote in message
news:Pine.A42.3.96.1030820164103.24956G-100000@[EMAIL PROTECTED]
>
> On Wed, 20 Aug 2003, Olaf Wagner wrote:
>
> > > Has someone experiences with this design decision or is there
someone
who
> > > can give hints and conventions for using exceptions in general?
> >
> > The conventional approach used in the standard libraries seems to be
> > to use EXCEPTION(AtomList.T). You can then specify the exact error
> > and additional useful information in the list elements.
>
> I have not used Atoms so far, they look like TEXTs that are prepared for
> fast comparison. AtomLists in exceptions seem to be used for storing
human
> readable error descriptions. Why lists? To keep exceptions that occured
> while handling another exception? What's about "machine readable"
> information like numbers?
>
> > But this should not generally forbid to single out certain errors as
> > their own exception, depending on easiest use
>
> That's the central question which is hard to answer ... at least not
> before intensive usage. But after intensive usage it is hard to change.
> :-(
>