On 12/12/05, Cory Nelson <phrosty@gmail.com> wrote: [snip]
In the current asio implementation, a handler looks like this:
void on_recv(const asio::error &err, size_t len) { if(!err) { ... } else { ... } }
In .NET, a handler looks like this:
void on_recv(IAsyncResult res) { int len; try { len=sock.EndRecv(res); } catch(SocketException ex) { ...; return; }
... }
The key difference is that asio allows you to check the error but doesn't force it.
In .NET, EndRecv *must* be called to get the result of the operation. A result either being a valid return or an exception. By forcing accountability it plugs a reliability hole.
An added benefit of this is that calling an End* method in .NET will block if the operation isn't finished, so that option is there if you need it.
Nearly all of the STL (the only exception I can immediately think of being streams) throws exceptions on error, why should asio break from the norm?
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 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. What do you think Cory? and you Christopher?
-- Cory Nelson http://www.int64.org
-- Felipe Magno de Almeida