Why exceptions for error handling is so important

[via Digitalmars-d]

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++.