
Christopher Kohlhoff <chris <at> kohlhoff.com> writes:
Yes, that's not a bad idea. Of course, you don't want to rewrite all the forwarding functions with any regularity, so it's probably better to do this with a Handler object, constructed with an error-handling function and then supplied with the success-handling function for each new operation.
It'd be great if you could have a think about the interface for this object.
Sure, although probably not before the end of the review period.
Perhaps it's been discussed, but is there any particular reason you wouldn't want to define an 'asio::socket_error' subclass of asio::error? Attaching the relevant shared_ptr<socket> to the error code would make some error- handling strategies simpler.
I'm not sure that would be being useful enough in general, but perhaps a function object that automatically created a std::pair (or maybe boost::tuple) from the underlying asio::error and whatever you want to attach to it, e.g.:
sock->read(bufs, throw_error_pair(sock));
Thats sounds very reasonable. I wish I had some code to test it on... <snip>
I think we've lost track of the original point we were discussing here, whatever it was :) Basically asynchronous operations do not throw unless:
- Something really serious has happened, like running out of a critical OS resource.
- The user code throws an exception, or calls some other code that throws an exception.
In both cases I think the appropriate place to handle these exceptions is outside of demuxer::run().
Yes, I was talking more about the case of a generic handler-wrapper that responded to error conditions by throwing, or a variant of the existing library that would throw exceptions. But you're right, the point is lost. I guess my question boils down to, 'is there an error-handling strategy that could be applied to asio, that frees sockets programming from (tedious, error-prone) manual inspection of return codes?'. You seem to be accustomed to the current situation, while I'm still groping around and hoping you'll hit on a solution for me :) Matt