Link Details

Hey, it's April 5th, not April 1st!

What's with that?

It's a hoax. Isn't it?

Definitely not a hoax. Why would you think so?

When you have a hammer everything looks like a nail... Wouldn't this be enough (considering that you already chose to use auxliary variable):

boolean method() {

  boolean result = false;

  if ( conditionA )

    result = resultA;

  if ( conditionB )

    result = resultB;

  if ( conditionC )

    result = resultC;

  log( result );

  return result;

}

Yes, I agree it's a nice trick but it's not what the try{} blocks are for. They're just too much overkill for such a simple taks (the more code inside try{} the bigger overkill it is).

You assume conditions are exclusive. They usually are not.

You can alter the above with else-ifs and you'll get the desired result. But that's not the point. I made the point in the previous comment.

And I made the point about the else-ifs in the post. They make code really unreadable.

Why do you assume try-finally is not for that? It's just the exit block, performance-wise it's ok, semantics is clear. Why is that anyhow bad? It just gathers the logics in one place and still allows using many exit points, which is more comfortable in a number of cases. It's not a "pattern", but I think it's a nice idiom to keep your code clean.

Well, you're talking about the finally{} part only but I'm talking about the try/catch/finally block as a whole. The reason it's there is to try to execute some code than can fail potentially in an abnormal way but I'm sure you already knew that. And if you really think that enclosing code in the try{} doesn't hurt performance then just do yourself a favor and test both versions - with and without try{}. I did. :)

try/catch/finally semantics is that finally {} block will always be called before exiting the try {} block. Catch {} block will be called matching the exception. That's pretty much it.

I don't know what microbenchmark you used to test performance, but all this adds is a jsr/ret instruction pair for each return, which is extremely cheap. Oh, and also the catchall exception handler, but it never gets called if there's no exception, so its overhead is zero :)

That's not pretty much it. If you see the try/finally statement as just a neat way of collecting all your exit code in one place then sorry but I don't buy it. But it's fine with me as long as I don't have to maintain such code. :] And if you really want to be precise about semantics and nomenclature - the finally{} block gets executed after exiting the try{} block but before exiting the try/finally statement.

I guess we agree to disagree :)