Re: [boost] Asio formal review

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-17 14:42:18

From: "Christopher Kohlhoff" <chris_at_[hidden]>

> Hi Matt,
> 
> --- Matthew Vogt <mattvogt_at_[hidden]> wrote: <snip>
> 
>> I would like to see a user-supplied handler option for
>> handling genuine errors, not per-call but at a higher level
>> (maybe per-demuxer?)  Typically, the response to an error is
>> to close the socket,  once open; it would be handy to supply a
>> callback which received enough context to close down a socket,
>> and in all other code to ignore error-handling completely.
> 
> I'm not convinced that this belongs as part of asio's interface,
> since there are a multitude of ways to handle errors. For
> example, there's the issue of what happens in async operations,
> such as asio::async_read, that are composed of other async
> operations. You wouldn't want the application-specific error
> handling to be invoked until the composed operation had finished
> what it was doing.
> 
> I think the go is to use function object composition at the
> point where you start the asynchronous operation, e.g.:
> 
>  async_recv(s, bufs, add_my_error_handling(my_handler));
> 
> or perhaps:
> 
>  async_recv(s, bufs,
>    combine_handlers(error_handler, ok_handler));
> 

I agree with Matt that a clearer separate error path
is worthwhile, 
but also with Chris that functional composition is the way to go, 
but also with Matt that it should be part of the library. 

I'd prefer an interface like the latter option above, but
named something more appropriate to its error filtering
approach than combine_handlers

 async_recv(s, bufs,
        asio::split_errors(error_handler, ok_handler));

I've used a similar approach in writing asynch
voice applications and found that 
the approach scales up well, i.e. that higher and
higher level composed objects can be created
right up in to the application level code 

(e.g. in voice apps implement a menu, with complex 
internal logic that chooses an exit path based
on what key the user hit, and with error paths
if they pressed nothing, or hung up)

In networking this can correspond to implementing
branching in the reception of messages
(e.g. based on the contents of a header portion,
branch down a suitable path to receive/parse
different variable portsion).

Do you think there's scope for a toolkit to 
support this style of coding in asio, or would
that be a higher level thing. 

Cheers

Simon