うん、他の人が言ったように、try
ブロックは全体のいくつかの最適化を阻害します{}
それを取り巻くキャラクターします。特に、オプティマイザは、ブロック内の任意のポイントで例外が発生する可能性があると想定する必要があるため、ステートメントが実行される保証はありません。
例えば:
try {
int x = a + b * c * d;
other stuff;
}
catch (something) {
....
}
int y = a + b * c * d;
use y somehow;
なしではtry
、割り当てに計算された値をx
「共通の副次式」として保存し、再利用してに割り当てることができy
ます。しかし、try
、最初の式が評価されたという保証がないため、式を再計算する必要があります。これは通常、「直線的な」コードでは大したことではありませんが、ループでは重要な場合があります。
ただし、これはJITCされたコードにのみ適用されることに注意してください。javacが行う最適化の量はわずかで、バイトコードインタープリターがtry
ブロックに出入りするためのコストはかかりません。(ブロック境界をマークするために生成されるバイトコードはありません。)
そしてベストのために:
public class TryFinally {
public static void main(String[] argv) throws Throwable {
try {
throw new Throwable();
}
finally {
System.out.println("Finally!");
}
}
}
出力:
C:\JavaTools>java TryFinally
Finally!
Exception in thread "main" java.lang.Throwable
at TryFinally.main(TryFinally.java:4)
javap出力:
C:\JavaTools>javap -c TryFinally.class
Compiled from "TryFinally.java"
public class TryFinally {
public TryFinally();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]) throws java.lang.Throwable;
Code:
0: new #2 // class java/lang/Throwable
3: dup
4: invokespecial #3 // Method java/lang/Throwable."<init>":()V
7: athrow
8: astore_1
9: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
12: ldc #5 // String Finally!
14: invokevirtual #6 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
17: aload_1
18: athrow
Exception table:
from to target type
0 9 8 any
}
「GOTO」はありません。