Exception as the primary error handling mechanism?

[MRAB]

Michi wrote:
> On Jan 4, 1:30 pm, Steven D'Aprano
> <ste... at REMOVE.THIS.cybersource.com.au> wrote:
[snip]
>>>  * Is it appropriate to force the caller to deal with the condition in
>>> a catch-handler?
>>>  * If the caller fails to explicitly deal with the condition, is it
>>> appropriate to terminate the program?
>>> Only if the answer to these questions is "yes" is it appropriate to
>>> throw an exception. Note the third question, which is often forgotten.
>>> By throwing an exception, I not only force the caller to handle the
>>> exception with a catch-handler (as opposed to leaving the choice to the
>>> caller), I also force the caller to *always* handle the exception: if
>>> the caller wants to ignore the condition, he/she still has to write a
>>> catch-handler and failure to do so terminates the program.
>> That's a feature of exceptions, not a problem.
> 
> Yes, and didn't say that it is a problem. However, making the wrong
> choice for the use of the feature is a problem, just as making the
> wrong choice for not using the feature is.
> 
>>> Apart from the potential performance penalty, throwing exceptions for
>>> expected outcomes is bad also because it forces a try-catch block on the
>>> caller.
>> But it's okay to force a `if (result==MagicValue)` test instead?
> 
> Yes, in some cases it is. For example:
> 
> int numBytes;
> int fd = open(...);
> while ((numBytes = read(fd, …)) > 0)
> {
>     // process data...
> }
> 
> Would you prefer to see EOF indicated by an exception rather than a
> zero return value? I wouldn't.
> 
I wouldn't consider zero to be a magic value in this case. Returning a 
negative number if an error occurred would be magic. A better comparison
might be str.find vs str.index, the former returning a magic value -1.
Which is used more often?

>> Look, the caller has to deal with exceptional cases (which may include
>> error conditions) one way or the other. If you don't deal with them at
>> all, your code will core dump, or behave incorrectly, or something. If
>> the caller fails to deal with the exceptional case, it is better to cause
>> an exception that terminates the application immediately than it is to
>> allow the application to generate incorrect results.
> 
> I agree that failing to deal with exceptional cases causes problems. I
> also agree that exceptions, in general, are better than error codes
> because they are less likely to go unnoticed. But, as I said, it
> really depends on the caller whether something should be an exception
> or not.
> 
> The core problem isn't whether exceptions are good or bad in a
> particular case, but that most APIs make this an either-or choice. For
> example, if I had an API that allowed me to choose at run time whether
> an exception will be thrown for a particular condition, I could adapt
> that API to my needs, instead of being stuck with whatever the
> designer came up with.
> 
> There are many ways this could be done. For example, I could have a
> find() operation on a collection that throws if a value isn't found,
> and I could have findNoThrow() if I want a sentinel value returned.
> Or, the API could offer a callback hook that decides at run time
> whether to throw or not. (There are many other possible ways to do
> this, such as setting the behaviour at construction time, or by having
> different collection types with different behaviours.)
> 
Or find() could have an extra keyword argument, eg.
string.find(substring, default=-1), although that should probably be
string.index(substring, default=-1) as a replacement for
string.find(substring).