From: Michel André (michel.andre_at_[hidden])
Date: 2003-11-10 17:42:21
>>> 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.
>> The main reasons for me to suggest that was that in case of exceptions
>> and asynchrounous sockets is that its the exception could be thrown
>> asynchrounously in a thread that didn't make the request but in the one
>> dequeuing the completion.
>Your point being that using exceptions in this case is not possible?
Certainly possible but, personally I think it would be strange if
proactor::run in one of my dispatcher threads throw an exception that some
network operation failed on a unknown connection.
>> And that it is hard to associate the socket
>> instance with the error in case several sockets is associated with a
>> reactor/proactor instance.
>So would a call to the UserConnection's on_error method with an error
>code suffice? Do you have a concrete example of when you have needed
>to explicitly handle error codes, other than those associated with
>connection closure or flow handling (eg WOULD_BLOCK or IO_PENDING)?
No! The usual reaction to a socket error in applications I have written is
logging the error together with context information regarding the connection
and closing the connection generated the error.
An on_error method in the UserConnection would suffice with the same
signature as in the error policy with function::name and error.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk