Comments on: Yet Another Java Trick

By: dow.ngra.de » Blog Archive » Yet Another Java Trick, Revisited

dow.ngra.de » Blog Archive » Yet Another Java Trick, Revisited — Tue, 10 Jun 2008 16:14:15 +0000

[...] enough I rewrote by now both places in code that I did according to the Yet Another Java Trick. It’s a neat trick, which may come back to me in some other context, but it definitely [...]

By: Jevgeni Kabanov

Jevgeni Kabanov — Mon, 14 Apr 2008 07:12:14 +0000

It’s not a problem, you just have to have a sensible default result. If there isn’t any just don’t use this idiom :) In my case false was the acceptable default.

By: Tao Wang

Tao Wang — Sun, 13 Apr 2008 18:34:32 +0000

There is a problem when an exception threw with in the condtions like conditionA.
such exception will cause the method with no return value, but logged with result False.

By: Behrang

Behrang — Tue, 08 Apr 2008 06:41:11 +0000

@Kuhn: setter is void, it cant return value.

By: Jevgeni Kabanov

Jevgeni Kabanov — Mon, 07 Apr 2008 21:40:33 +0000

CyberMandrake: “I’ve read somewhere” is not the best argument. Try-finally in such a case should not anyhow significantly impair performance. It is in fact pretty same as just copying the finally block before every return (try-finally is implemented by doing a JSR jump before return an the RET jump when the block is finished, both are very cheap). If try-catch-finally would cost much the whole Java model would be broken, because checked exceptions mean you catch them a LOT.

By: CyberMandrake

CyberMandrake — Mon, 07 Apr 2008 19:45:48 +0000

Kuhn: Sure this looks creepy !!!
All: I’ve read somewhere that using try-catch blocks may impair the performance, because of the way bytecode should be generated, or smth else. So I would take care with this trick and use only in really complicated if nests and lairs. The simple example would not be the case, as is the real example above mentioned.

By: Adrian Kuhn

Adrian Kuhn — Mon, 07 Apr 2008 14:01:17 +0000

Cool.
Reminds me of this trick (encountered first in the sources of javac itself!)

// sets value and returns old value
public void setter(Object value) {
try {
return this.value;
}
finally {
this.value = value;
}
}

By: Jevgeni Kabanov

Jevgeni Kabanov — Sun, 06 Apr 2008 20:02:24 +0000

Axel: It’s a matter of taste. But I think that if you are already creating extra methods then delegating the actual functionality is better than delegating the logging (that is you should rename the method() to doMethod() and create a method() that does the logging).

By: Axel Rauschmayer

Axel Rauschmayer — Sun, 06 Apr 2008 18:44:54 +0000

How about the following?

public static X log(X arg) {
logItSomehow(arg);
return arg;
}

Then you can write the following (which is more conventional than your code, but also smaller and almost AOP):

boolean method() {
if (conditionA) return log(resultA);
if (conditionB) return log(resultB);
if (conditionC) return log(resultC);
}

By: kretes

kretes — Sun, 06 Apr 2008 16:14:12 +0000

Well – actually -> the real Aspect approach would be to seperate the logging from the rest of logic in the application. Then You wouldn’t have to write any wrapper for your method nor introduce not easy readable and straight solution with try-finally. You would just have to specify in the aspect, that You have to log something , while finishign executing of this method. In my opinion – AOP is a thing that should be another step into beatufil software architecture.

Anyway – nice trick ;-)