Benchmark of try/catch

[grauzone]

 From your site:

 >Having fast exceptions is getting more important, for example it's
 >important to have fast exceptions in Python because there they are
 >sometimes used to control flow too. For example to convert a string to
 >int/float the common Python idiom is to use a try/except.

I disagree. Exceptions shouldn't be abused as a second return value. The 
correct way would be to return an algebraic type. The return value would 
either contain the result of the function call, or an object that 
describes the error (like with exceptions).

And actually, I wonder if exception handling really leads to better 
error handling. Maybe it makes it even _worse_, because the fact, that 
the function call can fail with an error (exception), isn't explicit 
part of a function signature anymore. It isn't really obvious anymore to 
the programmer, which exceptions might be thrown. Further, a programmer 
might get the wrong impression that errors are handled automagically and 
he doesn't really need to care. Sometimes I get the impression, that 
exceptions are so loved, because programmers think they can ignore error 
handling when using them.

When I write C code, I know that ignoring return values can lead to 
horribly hard to locate bugs, and I force myself to check the return 
value (even if it doesn't seem important). This means I actually design 
some kind of failure path in my code. In D, the exception mechanism 
seems to move the actual error handling to somewhere "far away" (down 
below in the call stack). But actually, you end up never adding real 
error handling. Not even crappy error handling, like it's the case with 
most C code.

Even more, to obtain the exception as a "second return value", you have 
to use that painful try-catch statement, which adds a lot of noise to 
your code. There's also that problem (I think Andrei mentioned it) that 
try-catch introduces a scope, and this interacts badly with auto and 
various other things. Checking a return value would be more straight 
forward.

Using exceptions in a string->int conversion routine is really horrible 
and incredibly stupid. It raises all these issues, just because you 
can't signal failure in a better way. For parsing input, failure should 
be something to be _expected_, not an _exception_. You always want to 
check for success, but you don't force the programmer to check; instead, 
you'll make it harder by requiring the programmer to add this awkward 
try-catch thing around the function call.


There are some more things one could criticize, and possible solutions 
one could discuss (like reviving checked exception in a non-sucky 
version), but I'll stop now.

/rant