Detlef Vollmann wrote:
Andrey Semashev wrote:
I wouldn't say that it would narrow the language in some way. You still get the same functionality, only error reporting mechanism is in question. Using exceptions for this purpose is, well... following the language spirit, so to say, while mandating a dual approach honors code diversity. I happened to support some code that used both exceptions and error codes for error reporting, and I must say it was a pain. I think, at least for educational purposes one form of functions (the throwing one) should be highlighted as preferred. Maybe I missed something, but the subject still says 'filesystem'. And especially in that domain it's often that an error is not exceptional, e.g. 'file not found' or 'EAGAIN'. And errors that aren't exceptional shouldn't be reported and handled by exception throwing (and catching). What is exceptional and what not depends on the actual application, hence the two different forms.
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.