Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk