|
Boost : |
From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 2005-12-12 09:06:31
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk