The title of this HN submission is subtly misleading. The original post discusses the fact that Java's exceptions are slow, but merely as a symptom of the main problem: Java mixes up the issues of (a) finding some code that knows how to handle an exceptional condition and (b) backing up the call stack until it can find some code to continue executing. In Java, (b) is unavoidable, so the context of every exception is destroyed before the exception handler can examine it.
As noted elsewhere in this discussion, this means that Java exceptions aren't resumable [1] and that a Java exception can't examine all the variables that were alive when the exception was thrown and take action (like: logging) based on the values of those variables [2]. Plus there may be memory-usage implications. All of which are dimensions of suck that are independent of the speed issue.
---
[1] Not that I really know what this means, having never learned a language where this was possible.
[2] This, on the other hand, would be win that I could understand.
By doing this you will get something highly similar to CL's conditions. In CL, there is mechanism similar to Java exceptions (throw/catch/unwind-protect) that is - among other things - used by condition system to actually unwind stack when it determines that is necessary. So you can probably abuse Java exceptions to implement condition system or - more generally - escape continuations.
Problem is that such mechanism has to be used consistently everywhere to be useful. And when you find yourself rewriting standard library, you could well use CL instead of Java.
Exceptional doesn't mean once in a blue moon; it just means "not the normal flow", for example, it could mean missing data, which could be handled by returning and testing for a null in Java. Python has more efficient exception handling, so missing data is often handled by an exception. Programmers are encouraged to use this idiom. It has the advantage that the return value space is not cluttered by a distinguished error value. If a function returns an integer, is the error value 0, -1, or 9999?
From casually looking at both CPython and JVM code I conclude that implementation of exception handling in Java and Python is almost same. So this is more a cultural difference than effectiveness issue.
In Java you can do stuff like, the JVM is going to bounds check you anyway, so why bother checking yourself if you're about to go off the end of an array? Just i++ and catch IndexException (or whatever it's called).
There is more to consider with exception handling than just the performance of when the exception is thrown. There can also be performance penalties with respect to setting the stack up to be exception recoverable.
Also, there are some domains where the speed of recovery of an exceptional condition can be important.
You can't just use a tired old quote to hand-wave away optimization when it is important. You have no control over optimization of the language itself, so often it is important to consider performance aspects of a language when selecting a tool for a job.
An exception may not necessarily be an exceptional condition - e.g. Cannot parse integer, cannot open file might legitimately occur in code. In my APIs I usually try and make a very strong distinction between Exceptions and "Alternate Paths".
The thing is, many languages and APIs use the same mechanism for both - or at most offer checked and unchecked varieties.
For me, there is a big difference between an exception that the client can and can't remediate - e.g. "file not found" as opposed to "database down".
I thought the complaint about slowness was about the try clauses, which of course are paid for whether an exception occurs or not. Did I miss something?
There are a lot more important things to make sure are fast.
If most of your CPU time is spent throwing Exceptions, something is probably seriously wrong.