Boost logo

Boost :

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2003-11-10 15:25:28

Michel André wrote:

> Ok this sounds fair enough. With the new asynch like model is error
> policy needed shouldnt there be an socket_errno sent with each
> notification or an on_error notification that can be hooked on the
> connection class?


> How is errors communicated to the on_read/on_write handlers communicated,
> via the policy?

Preffered error handling is something that seems very subjective, so I
think we need to be flexible in how errors are reported. I am not sure
if this is right yet.

I'll explain how error handling works at the moment with connection (much
the same applies to acceptor and connector).

The way the classes use each other is something like below:

    --- net::connection
        --- net::socket::connection
            --- net::socket::socket

At the moment the socket returns platform independent, socket specific
error codes.

net::socket::connection use the socket error codes,
   i) handles some error codes, eg, if a read returns
      or if it returns 0 bytes read, then it closes the underlying socket
and a
      connection (socket/pipe independent) error code indicating closure is
      returned to net::connection after UserConnection::on_close is called.

   ii) unhandled socket errors are sent to net::socket::connection's error
       at the moment this just prints the system error message, but
throwing an
       exception or calling a UserConection::on_error should all be
possible as
       different policies.

net::connection uses the connection errors returned by
   All errors are handled by net::connection's error policy

I think I would shy away from providing error codes to the user level
read/write completion notification functions, unless a compelling case to
do so is found. I am a little more open to providing some reason code to
on_close, but even there I am not sure.


Boost list run by bdawes at, gregod at, cpdaniel at, john at