[REBOL] Re: async interface
From: rotenca:telvia:it at: 12-Mar-2004 1:26
Hi Gabriele,
> RPT> dns-failure
> RPT> connect-failure
>
> Why not using only one function for all errors?
I do not like to handle errors in rebol. I must disarm the error, check the
right field, know what code/type/id/arg I must find to understand what kind of
error is. Some errors are created by handler, other are real i/o errors, other
was errors and now are words ('close).
We could also create a new class of errors, else some different errors will be
of the same code/type/id:
800/user/message
and can be distinguished only by the arg1 field. For example:
>> probe disarm make error! "read-io aborted"
make object! [
code: 800
type: 'user
id: 'message
arg1: "read-io aborted"
arg2: none
arg3: none
near: [probe disarm make error! "read-io aborted"]
where: none
]
>> probe disarm make error! "write-io aborted"
make object! [
code: 800
type: 'user
id: 'message
arg1: "write-io aborted"
arg2: none
arg3: none
near: [probe disarm make error! "write-io aborted"]
where: none
]
My idea was:
use errors for "real" read-io/write-io errors
use 'close for peer close error
use 'max-retry or 'connect-failure for handler error: "max number of requests"
use 'dns-failure for handler error "can resolve host name"
> And, I think the connect event is useful, as you may want to start
> sending data when the connection is established and not before
> (imagine doing streaming).
the 'connect is not removed: it signals "connection done".
> RPT> This makes the multi function approach a lillte too complex, perhaps is
better
> RPT> to use the engage approach?
>
> Personally I prefer multiple functions, the problem is making that
> fit into the way ports are... maybe in the future they could have
> a feel object instead of the awake function.
I have a mode ;-)
Another solutions it to use the standard awake function with only the port
argument and a field in port/locals to store action or errors.
---
Ciao
Romano
