Though I agree with you that the asio error handling doesnt enforce the error check. IMO, the way .NET does isnt correct either. Not all errors in STL are reported by exceptions, and really shouldnt (Some are done by assertions, which means that error handling should be done by the application alone, like validations). Exceptions (as the name says) are for exceptional cases, I think that network errors arent that exceptional, and as such the use of exceptions could really slow down your program in certain patterns of use.
I agree completely. Exception generation should be optional. Exceptions can be easily layered on top of a more conventional error handling without performance penalities, but the other way around is much trickier.
I think that one possible solution would be that error checks would be than by the asio, and redirect it to another function if an error is found. That way could be binded two functions. It even seems to be possible to create auxiliary classes that does this things on top of the current asio library. It would even make the code a lot clearer, comparing to both .NET and current asio usage.
I've done exactly that in my network library (although it does support only synchronous behaviour). An optional error handler functor is passed to every functions that can generate an error. If no handler is passed a default handler is used that converts errors in exceptions. It works quite well. The user need to explicitly check for errors only if it wants to, else exceptions are used.