Questions about conditions

[Dustin Voss]

I'm trying to get a better grip on conditions and handlers, and I have
two questions.

The first question I have is about the behavior of 'let handler', which
can have following syntax:

let handler <simple-error>,
init-arguments: #[format-string:, "disconnected port %s",
format-arguments:, #["com1"]]
= try-recovery;

That handler will catch the condition generated by the following call (a
<simple-error> formatted with "disconnected port %s", "com1"):

cerror("reconnected port %s", "disconnected port %s", "com1");

This is all fine and good. The DRM says the init-arguments: option "is a
sequence of alternating keywords and objects that can be used as
initialization arguments to construct a condition to which the handler
is applicable." On page 106
(http://www.opendylan.org/books/drm/Signalers_Conditions_and_Handlers),
the DRM says "an applicable handler is one that matches the signaled
condition by type and by an optional test function associated with the
handler."

What the DRM does NOT say is how the init-arguments: option determines
applicability. What I want to know is what happens when the handler is
defined like this:

let handler <simple-error>,
init-arguments: #[format-string:, "disconnected port %s"]
= try-recovery;

Will this handler catch both the following signals, or is it not
applicable to either one?

cerror("reconnected port %s", "disconnected port %s", "com1");
cerror("reconnected port %s", "disconnected port %s", "com2");

Ideally, the handler would catch both. That would actually make it
useful. Otherwise...not so much, because you'd have to define a separate
handler for every combination of initialization arguments.

The second question I have is also about 'let handler'. The DRM says the
handler can handle a condition by "tail-recursively calling signal of a
restart." This isn't strictly true, is it? The handler is like any other
function and can return the values of 'signal' on any condition class,
not just <restart>?

Aside from that, I think I grok conditions and handlers, but I'd like to
check my understanding. Have I got it right?

A recovery protocol describes what values 'signal' or 'error' return (if
any) and what restarts the signaler should support (if any).

The 'error' function assumes (and ensures) that the recovery protocol
does not allow for return values. So it should not be used to signal a
<warning>.

The 'signal' function does not make any such assumption, and can be used
to signal an <error> or a <warning> or any other condition.

When you define a new condition class, you should define its recovery
protocol. But the new recovery protocol has to be compatible with its
superclass' protocols, i.e. you cannot define a subclass of <warning>
called <my-warning> and say the recovery protocol does not allow for
return values.

This is because if you signal a <my-warning> using 'error' (since the
recovery protocol says the signaler shouldn't expect return values), a
<warning> handler may still catch the condition (instead of a
<my-warning> handler) and attempt to return a value, thus causing an
error.

You can recover, retry, or restart without using the <restart> class, by
simply returning values from the handler, and having a signaler that
knows you can do this and retries or continues the operation when you do.

However, the <restart> class allows a recovery protocol to specify
several different recovery methods, and allows a signaler to recover
without needing to deal with return values from 'signal'.

Thanks in advance!

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDem

[Chris Page]

Dustin Voss wrote:
> What the DRM does NOT say is how the init-arguments: option determines
> applicability.

It doesn't. You've probably been misled by the sentence "The condition
describes the conditions for which the handler is applicable." and the
fact that init-option is discussed under that bullet point. That
sentence must be interpreted more liberally.

Only the type and test-option options determine handler applicability.

The init-arguments provide a means for introspectively examining the
available handlers and then constructing a condition object that a
given handler can handle, using the init-arguments to construct the
object. But that's all the init-arguments are for: constructing a
condition object that the handler could handle. In fact there's no
guarantee that it will handle it, since the test-option could use
additional rules, such as the state of some global variable.