From: "Christopher Kohlhoff" <chris@kohlhoff.com>
Hi Matt,
--- Matthew Vogt <mattvogt@warpmail.net> 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