Re: [boost] Asio formal review

From: Matt Vogt (mattvogt_at_[hidden])
Date: 2005-12-28 23:00:28

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