Boost logo

Boost :

From: christopher baus (christopher_at_[hidden])
Date: 2005-12-12 10:56:49

> On 12/12/05, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> wrote:
>> On 12/12/05, Cory Nelson <phrosty_at_[hidden]> wrote:
>> >
>> > For the API, one thing that struck me is the almost C-style error
handling. I believe the .NET way is better. It provides a point
>> > the developer must call to get the result of the operation, and that
the sockets can throw any exceptions that would normally be thrown in
sync operations.
>> >
>> > [snip]
>> Could you elaborate a little more about what you mean with C-style
error handling and the error handling you prefer (.NET) ?
> 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; }
> ...
> }

IMHO, I would not accept an implementation that forces exception handling
onto the user. Consider a common use case for this library: high
performance, internet facing servers. In this .NET style example, an
exception would be thrown when the peer drops connection while the
application is waiting for data, increasing the overhead of the error

An attacker attempting a DoS on the server looks for cases which increase
the response time. In this example the attacker could flood the server
with broken connections forcing a significant amount of CPU time to be
spent in exception handling.

Exceptions might be appropriate for higher level services, but not a
requirement for the core dispatcher.

Boost list run by bdawes at, gregod at, cpdaniel at, john at