Exception as the primary error handling mechanism?

[Michi]

On Jan 5, 9:44 am, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
>
> I'm glad we agree on that, but I wonder why you previously emphasised
> machine efficiency so much, and correctness almost not at all, in your
> previous post?

Uh… Because the original poster quoted one small paragraph out of a
large article and that paragraph happened to deal with this particular
(and minor) point of API design?

> If all you're argument is that we shouldn't write crappy APIs, then I
> agree with you completely.

Well, yes: the article was precisely about that. And the point about
exception efficiency was a minor side remark in that article.

> Your argument seems to be
> that we should avoid exceptions by default, and only use them if
> unavoidable. I think that is backwards.

I never made that argument. After 25 years as a software engineer, I
well and truly have come to appreciate exceptions as a superior form
of error handling. I simply stated that throwing an exception when
none should be thrown is a pain and often inefficient on top of that.
That's all, really.

> I wouldn't say that's normal. If you don't care about the function's
> result, why are you calling it? For the side-effects?

printf returns a value that is almost always ignored. And, yes, a
function such as printf is inevitable called for its side effects. We
could argue that printf is misdesigned (I would): the return value is
not useful, otherwise it would be used more. And if printf threw an
exception when something didn't work, that would be appropriate
because it fails so rarely that, if it does fail, I probably want to
know.

> > However, if a function throws instead of
> > returning a value, ignoring that value becomes more difficult for the
> > caller and can extract a performance penalty that may be unacceptable to
> > the caller.
>
> There's that premature micro-optimization again.

Let's be clear here: the entire discussion is about *inappropriate*
use of exceptions. This isn't a premature optimisation. It's about
deciding when an exception is appropriate and when not. If I throw an
exception when I shouldn't, I make the API harder to use *and* less
efficient. The real crime isn't the loss of efficiency though, it's
the inappropriate exception.

> I've been wondering when you would reach the conclusion that an API
> should offer both forms. For example, Python offers both key-lookup that
> raises exceptions (dict[key]) and key-lookup that doesn't (dict.get(key)).
>
> The danger of this is that it complicates the API, leads to a more
> complex implementation, and may result in duplicated code (if the two
> functions have independent implementations).

Offering a choice in some form can be appropriate for some APIs. I'm
not advocating it as a panacea, and I'm aware of the down-side in
increased complexity, learning curve, etc. (BTW, the article discusses
this issue in some detail.)

> Well, obviously I agree that you should only make things be an exception
> if they actually should be an exception. I don't quite see where the
> implication is

In the context of the original article, I argued that throwing
exceptions that are inappropriate is one of the many things that API
designers get wrong. To many people, that's stating the obvious. The
number of APIs that still make exactly this mistake suggests that the
point is worth making though.

Anyway, some of the early posts implied that I was arguing against
exception handling per-se because exceptions can be less efficient. I
responded to correct that misconception. What the article really said
is that throwing an exception when none should be thrown is bad API
design, and inefficient to boot. I stand by that statement.

Cheers,

Michi.