> He claims exceptions are fast enough. This is going to vary across languages. In cPython for instance (since I happen to know it), exceptions are at least as

> He claims exceptions are fast enough. This is going to vary across languages. In cPython for instance (since I happen to know it), exceptions are at least as fast as looping through an iterator, since exiting from a loop is done via exceptions. He included a link to an article showing that exceptions are quite fast on the JVM. I am sure there are other languages where the implementation of exceptions is slow -- in these languages this is a valid objection to using exceptions for flow control. And I don't care how fast the code runs under a debugger. Perhaps you do, but really, I don't; we must have very different use cases. > He claims that it's not hard to understand, but provides no support. [...] I don't see the advantage - he's doing it differently, but what's the point? What's he winning? It ISN'T hard to understand if used in a consistent way... I don't need any further evidence of that than my own observations. But you are absolutely correct that the argument needs evidence of exceptions being clearer. Perhaps it would help to provide an example of a triple-nested loop with numerous boolean condition variables contrasted with the same loop using exceptions for exit. I don't think exceptions for flow control are more clear in all circumstances, or even in most circumstances, but I believe that they are in some circumstances, especially in cases where substantial work needs to be done in order to determine whether one should proceed: doing the work twice is inefficient, and splitting the function into part-A (everything before the decision point) and part-B (everything after it) can be much less readable than using an exception if part-A sets up variables and data structures used in part-B. > All the way back to dijkstra's article on goto such control flow existed, it just wasn't called the same. And exceptions are essentially non-local goto's. No, I think they are fundamentally different. The problem with GOTO, and with programming before structured programming was invented, was a problem with arbitrary ENTRY points; arbitrary EXIT points do not cause this problem. My more detailed thoughts on this can be found at http://mcherm.com/permalinks/1/in-defense-of-the-much-maligned-goto http://mcherm.com/permalinks/1/in-defense-of-the-much-malign... > Finally, he's doing an end run around the type system. This seems to be a completely new argument and one which wasn't addressed. I am very interested, but somewhat confused. How does the use of exceptions undermine the type system? Is it because the type of the function, instead of being "Returns an Int" becomes "Returns an Int or raises an exception"? If that happens for all functions, how is it confusing? Can you give me an example of how things could go wrong? > In a purely functional language with checked exceptions [...] if you use some nice monadic syntax sugar [...] the distinction between this approach and discriminated unions is very small. [...] why not just use discriminated unions in the first place? I agree, as long as the language syntax supports doing it easily that is the better approach.