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
