Boost logo

Boost :

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, gregod at, cpdaniel at, john at