Second, if you're going to publish a library, it's certainly important to have an error handling policy. But I find it very strange to assume that your clients will screw up error handling and blame you for it. The blog post doesn't say this explicitly, but I think it's the source of the "no exceptions, ever" policy ("no exceptions, because the clients will screw it up").
Third, you shouldn't throw exceptions for every error. You throw exceptions when something went wrong and you don't think your immediate caller can do anything intelligent about it. If the immediate caller can do something, you return an error code.
Fourth, did you know that printf() can fail? What should you do if it does? You can't print a warning to the user. Did you know that closing a file can fail? What should you do? Close it again? If a destructor is unable to clean something up, it's basically impossible to do anything about it. You might log the error, but I don't see what you'd do about it.
First, undefined behavior has an actual meaning in C++, and it's not "nondeterminism" ( http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-... , http://blog.llvm.org/2011/05/what-every-c-programmer-should-... ).
Second, if you're going to publish a library, it's certainly important to have an error handling policy. But I find it very strange to assume that your clients will screw up error handling and blame you for it. The blog post doesn't say this explicitly, but I think it's the source of the "no exceptions, ever" policy ("no exceptions, because the clients will screw it up").
Third, you shouldn't throw exceptions for every error. You throw exceptions when something went wrong and you don't think your immediate caller can do anything intelligent about it. If the immediate caller can do something, you return an error code.
Fourth, did you know that printf() can fail? What should you do if it does? You can't print a warning to the user. Did you know that closing a file can fail? What should you do? Close it again? If a destructor is unable to clean something up, it's basically impossible to do anything about it. You might log the error, but I don't see what you'd do about it.