Igor R writes:

...

I don't see in the documentation anything that says which error code could result from the various asynchronous calls.

Obviously, I would have to identify all connection related error codes and

...

the state of my process such that a reconnect was the way to handle it. In some cases a retry might be needed. However, I don't see a way to get a

set list

...

of the possible error codes that need to get checked for aside from hours and hours of debugging trial and error.

Does there exist somewhere a list of error codes that could result from async_read? which would I get from async_write?, async_accept? etc..etc.

I see it is a sytem::error_code, and I can look at the header, I can even find a doc that lists all of them and see asio has a group, but I can't tell which might occur when.

Most of error_code values come from the lower levels and they are just translated/propagated by asio to your application, so the error you get is not even platform-independent, i.e. on some platform you can get one error, while in the same situation on another platform you might get another error. But does it really affect states in your progam? Why is it important for your state-machine whether you get 10053, 10054 or 10060 error code?

Well, my main concern is for reads and writes over tcp. Determining if my connection has been dropped or is unrecoverable, or if I should retry the read or write. I see lots of 'no so self explanatory' error codes in the list of possibles. Such as, "Operation already in progress" "access_denied" "operation_aborted" knowing when and why these occur dictates how I would handle them and whether I'd give up or retry.

Well, my main concern is for reads and writes over tcp. Determining if my connection has been dropped or is unrecoverable, or if I should retry the read or write.

I see lots of 'no so self explanatory' error codes in the list of possibles. Such as, "Operation already in progress" "access_denied" "operation_aborted"

knowing when and why these occur dictates how I would handle them and whether I'd give up or retry.

I don't think you can recover from unexpected errors coming from tcp, by just "retrying read or write". The only thing you can do in any case is to try and re-establish connection.