On Thursday, 15 January 2015 at 21:48:25 UTC, Tobias M wrote:
But for almost every environmental error, there's a use case where it is normal or at least expected. That means, you have to have two versions of every function, one that throws and one that uses "normal" flow control.
Exactly. Just think about validation of user input. Is it a service or is it a test of environmental failure?
Oh, it is a service when you validate the input with a regexp, but if the database does the validation against the db schema then it is an environmental failure. Since it is normal for users to make mistakes we now have to do double work to satisfy the no-exceptions-regime.
Or take a XML validation service. Is failure to validate not part of normal operation, yes it is. So we cannot use exceptions. But if we retrieve the XML from a XML database, then failure to validate is not normal operation, so then we can use exceptions in the validator.
From a computational view the validators are doing the same work, that means the implementation should be the same too.
How can I (as the implementer of the "Create file" function) decide if a failure is actually expected or not? I can't, because I cannot foresee every use case of the function.
Reminds me of people who say that you should always test if a file exists before you open it. But to do that correctly you would have to put a lock on the file system since the file could be deleted between the test and the opening... And again, we are doing double work.
Great. With this regime in place "no overhead exceptions for normal operations" creates a lot of overhead since the computer have to do double work to avoid exceptions when using libraries and frameworks.
No wonder people don't want to use exceptions in C++.
