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:
At the moment the socket returns platform independent, socket specific
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
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
exception or calling a UserConection::on_error should all be
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk