adda`exceptions

1.8: adda/exceptions

[1.9: review of exceptions:
. there are 2 types:
# dialog-acceptions
are accepting a callback to resume,
(similar to the mac dialog) .
# failure-exceptions
are like the ada'exception,
which is simply canceling the job,
and asking the caller what it wanted to do
in the event a call had failed .
. failure-exceptions are part of the contract
between client(caller) and service(subroutine) :
the subroutine's list of exceptions
are telling the caller that if the call fails
then the reason for the failure will be given;
eg:
f`exception?
( [file not found]: handler#1
, [user unresponsive]: handler#2
) .
. if subprogram f didn't declare any exceptions?
or if you were not concerned with
the reason for the failure?
then you could simply use f's name
as an exception case:
eg,
exception?
( f: handler#1 .
, others: ... )
.
there are 2 ways for declaring exceptions:
. the ada way has symbols declared to be
an exception.type,
eg, (e.exception; raise e);
and then the caller can ask:
(was e raised?) .
. the other common way
is using the name of a datatype or class;
ie, you can ask:
"(was the failure from any operation owned by
number.type ?)
. along the same lines, you can be more specific
by asking which subprogram or operation
was in effect when the exception was raised .
eg,
asking "(did f cause the exception?)
would be the same as asking
"(was it any exception raised by f
or by employees of f ?
).

. exceptions should be part of the subprogram interface;
this is in contrast to ada's idea
which requires exceptions to be
packaged with a subprogram:
ie, instead of submitting just a sub' to the library,
the sub' and it's exceptions must be
components of a package;
then importing the package from the library
brings you both the sub' and its exceptions .

. when using subprogram names as exception cases,
there can be some confusion due to
overloading of sub' names,
so the syntax must allow for use of the full name
including the parameter types,
which may preclude the use of declarations
within an exception-casing.stmt
(atleast not at the top level);
[1.19: or,
overloaded operators can be viewed as
belonging to a particular datatype or package,
so then for function f belonging to t.type,
there would be the exception case: t`f .
. then using an overloaded name without qualification
would mean every member of the overload class . ]

. raising an exception means
asking whether any in command chain
is catching this exception,
if no,
then the system knows to hang up the whole process,
else
having an exception handler in the employer chain
gives the system a place to roll back to .
. this is all the info needed by the system
by runtime
the sub decides on exceptions to propagate;
if the sup happens to catch, ok .
todo:
. the details of this rollback require a review
of how nested and recursive subunits
complicate where on the stack an instance is .
todo:
. what does either say about
contracts and exceptions?

. even if a sub' doesn't declare an exception
then there are still certain system exceptions
that are implicitely declared for every sub' .
. it is very common for sub's to fail because of
misusing sytem resources, eg:
exception?
( [out of mem]: handler#1
, [access violation]: handler#2
, others: handler#3 ...
) .

1.20: exception/translation:

. anything you do with {setjump, signal}
can bring out bugs in compiler
and make your app less robust;
so, it's best to first check your sdk
for platform-specific ways to
make your app responsive to user interupts .
. while setjump is good at
quickly unwinding the stack,
can it really be the case
that a rarely occuring situation
is the right place to worry about being quick
at the expense of program stability ?
. signals may still be useful,
but platform-specific frameworks
usually provide you with full-featured
event-loop programming that includes
all the signals you'll need .

declaring dialog-exceptions:
. dialog-exceptions are just call-backs,
so a subprogram can declare them as globals
(see adda/dstr/param'blocks)