Olaf van der Spek wrote:
On Tue, Oct 27, 2009 at 7:47 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Why is it necessary to impose a single view on the language? Authors often give advice and situations demand certain concessions. Isn't it reasonable to accommodate many use cases? If you're too restrictive, you make C++ less appealing and users will choose other languages. Is that helpful? 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.
I think there's a difference between errors and exceptions. Exceptions shouldn't be used in all cases.
Then, perhaps, we should take a closer look at these errors. Does, for instance, failing to delete a file qualify as such non-exception error? Or failing to send data through a socket? IMHO, if an operation fails to fulfill its postconditions, it is an error that should be indicated with an exception. If, by the nature of the operation, the postconditions are allowed to fail (that is, it is normal for them to fail), then the postconditions are badly formed, and we are not speaking of an error in the first place.