|
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?
[snip]
> 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:
UserConnection
|
--- 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
connection_reset_by_peer
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
policy.
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
net::socket::connection.
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.
Hugo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk