3 ms·

I was going to do a post rebuking the points made, but rather unsurprisingly it seems plenty of others already have done so, in a manner much less arrogant than

• brazzy 14y ago
  Actually both those sources do nothing but repeat the non-arguments that TFA debunks.
• andyjpb 14y ago
  In the specific case of Java, it looks like the compiler understands that you might want to use exceptions for flow control or other things. How else would you explain behaviour such as this: http://jawspeak.com/2010/05/26/hotspot-caused-exceptions-to-lose-their-stack-traces-in-production-and-the-fix/ http://jawspeak.com/2010/05/26/hotspot-caused-exceptions-to-...
• mcherm 14y ago
  I would encourage you to do that post. Because the two documents you linked to are very unconvincing when placed beside David MacIver's essay. The first link (http://www.javaspecialists.eu/archive/Issue187.html http://www.javaspecialists.eu/archive/Issue187.html) says the code was hard to understand, that this is the 'wrong' way to use exceptions, that reusing a normal exception type instead of an exception intended for control-flow might mask other exceptions, and that debuggers will pause. These are MacIver's points #4, #2, #6, and #5 and he debunked each one. The second link (http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html?page=2 http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html?pa...) says "This not only makes the code difficult to read, but also makes it slower." That is MacIver's points #4 and #1 and he debunked them. Do you feel that any of MacIver's points are incorrect? Do you know of any arguments that he did not already address?
  • emn13 14y ago
    He didn't do any debunking. He merely asserted the opposite; and not very convincingly. He claims exceptions are fast enough. But though he proposes that exceptions are generally usable, he only backs this up for java, and AFAIK the statement is in general false. In other words, in most contexts, using exceptions for control flow is expensive. He claims that "decent debuggers" won't pause - but which decent debuggers is he talking about? Because that's not at all the norm. Furthermore, as soon as you attach a debugger, it's likely all exceptions are much, much slower. Having code that runs orders of magnitudes slower in debug mode is a problem in and of itself because it means that some issues can't be properly debugged. Furthermore, many debuggers are designed to work with convential code - in other words, if they let you filter exceptions, it's not in a practical way intended to be ideally usable as control flow. He claims that it's not hard to understand, but provides no support. If you're going to deviate from convention, you should have a reason; some argument. Merely the fact that it is conventional is a plus since that simplifies communication and maintenance. And frankly, having read his article, I don't see the advantage - he's doing it differently, but what's the point? What's he winning? He claims that the arguments against exceptions aren't well documented, but that's simply because he's searching rather narrowly. 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. Finally, he's doing an end run around the type system. This is about as problematic as a null reference; i.e. it's going to cause constant pain. You've documented your program by type annotation which is good for humans, good for API discoverability (autocomplete) and allows some static checking. By doing this you're adding a hole that isn't properly annotated. In some languages, e.g. java with checked exceptions, this is less of a problem (but then it's also quite wordy). And again, it isn't true in general - maybe for java. In a purely functional language with checked exceptions, I can see his argument holding water - Say, some Haskell variant. At that point, the distinction between this approach and discriminated unions is very small - indeed, if you use some nice monadic syntax sugar you could probably exchange the one for the other. But really, why not just use discriminated unions in the first place?
    • mcherm 14y ago
      > 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.