I know people say that one should only use exceptions in exceptional circumstances, but there are times when it seems to me that using try & catch would make my code a lot simpler than the alternative - a number of condtional return statements. Can the cost of throwing exceptions be avoided by instead of throwing a new exception, throwing a constant that extends the class Throwable?

A seminar at the last JavaOne covered this situation. There is still a small overhead in the try/catch handling itself, but Cas is right, most of the expense is in filling in the stack trace. A constant throwable should give you better performance.

That's pretty weird isn't it! I suppose I've never noticed because I only throw them where I want them...

But no, the overhead of throw/catch is massively greater than calling another method. I think this will even show up in a fairly small benchmark.

The Hotspot guys have designed their compiler to cater for the way it should be done; there's a lot more thinking gone in to making non-exceptional code function very fast instead of exceptional code which should theoretically be called in an exceptionally unusual circumstance.

This suggests that:(1) the cost of throwing exceptions can be reduced by a factor of at least 10 by using constants;(2) if exceptions are occur less frequently than 1 time in 12, then catching constant Throwables when exceptions occur is faster than calling canDoSomething() and avoiding throwing exceptions. (Obviously, this depends on how long the canDoSomething() takes to execute).

I've been using exceptions for quite a few things in the application server that I've been building for work. I haven't yet seen exceptions becoming a problem because they're only ever triggered during true error conditions when in most cases I need a stack trace going to log4j and a page going to a developer. Since I never have exceptions involved in application logic at all, I've never noticed any real issues and my application needs to churn through 14k business logic operations per second. Right now my app isn't even breaking a sweat - let alone causing any issues for the Solaris box hosting it. There may be places for improvement in the exception handling code, but is one of those situations where the benefit is so trivially small compared to having to do something that's outside the standard Java coding paradigm.

So I keep listing this type of thing in the 'optimization for the sake of doing optimization' category. Heck even on my PowerBook G4 I see very little point in going against the default behavior of Java. An exception should be a rare occurrence - else it isn't an exception... its a normal part of business logic that belongs in its own method

I was thinking about using exceptions in non 'exceptional circumstances' because it made the code clearer, however, I think swpalmer's suggestion of using breaks with labels solves the problem without using exceptions in a way they were not designed for.

The key issue with using the language in a way that it was not intended means you are effectively abusing an instance of its implementation, namely Sun's 1.4 JRE in this case. What about IBM's VM? What about the Mac port? And Linux? They are all very unlikely to treat exceptions in the same way. Furthermore, Sun can and probably will alter their VM to make the case without exceptions faster at some point in the future. Your existing code will get slower! Agh!

Another cost of exceptions is in optimizations: thr try/catch blocks will make harder for the optimizer to predict the program's control flow, especially when the exception is thrown by one method and caught by another. This will spoil inlining, constant propagation, register allocation etc., especially if the throw lives inside loops.

The JGF benchmarks revel that Sun HotSpot Server 1.4.x is pretty good with this -- so good that it detects simple loops of try/catchs (local throw, with pre-created exception) as dead code and produces infinite scores -- but the same doesn't happen with non-local throws, non-precreated exceptions, or in any case with any JDK 1.3.1 (including IBM's) or even with HotSpot Client (more likely to be used by games).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org