dialogging exceptions

7.28: adda/cstr/dialogging exceptions/
syntax and fleshing out semantics:
. in adda, dialogging exceptions are
the kind of exceptions which are not call-killing:
they simply give the caller a chance to
fix things in the event of a missing resource:
eg, if a service finds a parameter missing
such as when a file is found to be unreachable,
it will give the caller's file-missing handler
a chance to assign a new file url to an address .
[7.29:
. dialogging exceptions are basically like
implicit parameters that accept a procedure for
what to do in the case of an exceptional situation;
ie, in the usual exception,
the service is quitting and that kills
the whole block that called that service;
so control jumps to the block's exception handlers;
whereas, in the case of dialogging exceptions,
the service is not quitting;
it merely calls an exception handler .]

. for dialogging exceptions,
the handler is expected to return a resource;
so we need syntax for an exception's
returning a value;
it's like a signal but you need a
pointer or inout param because
it's not just reading but writing to the param .
. what if the handler can't help?
if the param is a pointer
it can return nil to indicate failure
indicating the handler is of no help,
so the service then knows to
clean up and throw a returning exception
or give some other indication of failure .
[8.8:
. it's just like a dialog is to the user;
and in that situation,
the user can either find the resourse
and ok the dialog, or cancel it .
. for our example, the service declares:
FileNotFound( f/.filename ).dialog;
-- notice the arg is a pointer type;
and then the handler responds like this:
# a return would be ( f/`= $the/find.txt; );
-- the "(/) is dereferencing the pointer;
and, the target is assigned a literal filename .
# a cancel would be ( f`= none )
-- the pointer itself is assigned no address .
ipc:
. how are we dealing with
pointers that are sent across processes
(ie, how is an arbitrary pointer being thread safe?);
well, in the case of exceptions there are no surprises;
because, it's by invitation only:
the exception raiser is providing an address
for the caller to put a patch into .

8.9: ok,cancel as dialog-local keywords:
. another idea is that the handler's parameter
needs to be an out-mode not a pointer;
and, to handle the dialog
it assigns to the parameter and calls ok;
if the handler has nothing to return,
then it calls cancel to
allow for the service to clean up,
and then it can either propagate an exception
or make a change in strategy,
and then exit from the enclosing block,
or enter some tagged block; eg,

( --. begin a block containing a dialog handler .
...
[service that needs a file](f)
-- call the service that may dialog later .
;
on FileNotFound( out f.filename ).dialog:
( f`= [find a new file];
[file was found] ? ok
else: ( cancel; raise MissingResource )
)-FileNotFound
) --end of block with a dialog handler .]