Andrey Semashev wrote:
I had experience with Boost.Filesystem, but I never had a single case when I needed an error code instead of an exception. So, unless I'm missing something, filesystem ops are better suited for exceptions than ASIO, that was claimed otherwise earlier in the thread. What I'm trying to say is that I think that if in particular case an exception is not desired, then this particular operation is not defined properly.
I don't know what kind of code you write, but I'll bet that it doesn't represent all of the needs of all of the different programmers who might use asio for their own purposes. Thus I don't think you can claim that exceptions are better than error codes in this domain just because you've never wanted error codes. I would also like to point out that you can trivially wrap an error code-based API with a throwing API that checks the error code and throws if an error occurred. Thus, if only one form is to be provided, and some users want error codes and some want exceptions, the error code version should be provided by the API. (If there are many users on each side, the API should probably provide both versions, probably by doing this kind of wrapping.) This is similar to how std::vector provides an unchecked operator[] -- you can build a safe facility (at()) on top of a fast one, but not the other way around. Since some users want speed and some users want safety, the library makes the flexible one the default, but provides both. --Jeffrey Bosboom