財政的にトライとトライキャッチの違い
-
27-09-2019 - |
質問
の違いは何ですか
try {
fooBar();
} finally {
barFoo();
}
と
try {
fooBar();
} catch(Throwable throwable) {
barFoo(throwable); // Does something with throwable, logs it, or handles it.
}
2番目のバージョンは、スロー可能なものにアクセスできるので、2番目のバージョンが好きです。 2つのバリエーションの間に論理的な違いや好ましい慣習はありますか?
また、最終句から例外にアクセスする方法はありますか?
解決
これらは2つの異なるものです。
- キャッチブロックは、Tryブロックに例外がスローされている場合にのみ実行されます。
- 最終的なブロックは、例外がスローされているかどうかにかかわらず、Try(-catch)ブロックの後に常に実行されます。
あなたの例では、3番目の可能な構造を示していません:
try {
// try to execute this statements...
}
catch( SpecificException e ) {
// if a specific exception was thrown, handle it here
}
// ... more catches for specific exceptions can come here
catch( Exception e ) {
// if a more general exception was thrown, handle it here
}
finally {
// here you can clean things up afterwards
}
そして、@codecaが彼のコメントで言っているように、最終的なブロック内の例外にアクセスする方法はありません。
もちろん、ブロックの外側に例外を保持する変数を宣言し、キャッチブロック内に値を割り当てることができます。その後、最終的なブロック内でこの変数にアクセスできます。
Throwable throwable = null;
try {
// do some stuff
}
catch( Throwable e ) {
throwable = e;
}
finally {
if( throwable != null ) {
// handle it
}
}
他のヒント
これらはバリエーションではなく、根本的に異なるものです。 finally
実行されます いつも, catch
例外が発生した場合のみ。
最後に、キャッチブロックはまったく異なります:
- キャッチブロック内で、スローされた例外に応答できます。このブロック 未処理の例外がある場合にのみ実行されます タイプは、Catch Blockのパラメーターで指定されているものの1つまたはサブクラスと一致します。
- 最後に、常に実行されます 試してみて、例外が提起されているかどうかにかかわらず、ブロックしてキャッチします。
それで
try {
//some code
}
catch (ExceptionA) {
// Only gets executed if ExceptionA
// was thrown in try block
}
catch (ExceptionB) {
// Only executed if ExceptionB was thrown in try
// and not handled by first catch block
}
とは異なり
try {
//some code
}
finally {
// Gets executed whether or not
// an exception was thrown in try block
}
大幅。
トライブロックを定義する場合、定義する必要があります
- 最終的にブロック、または
- 1つ以上のキャッチブロック、または
- 1つ以上のキャッチブロックと最終的にブロック
したがって、次のコードも有効です。
try {
//some code
}
catch (ExceptionA) {
// Only gets executed if
// ExceptionA was thrown in try block
}
catch (ExceptionB) {
// Only executed if ExceptionB was thrown in
// try and not handled by first catch block
}
//even more catch blocks
finally {
// Gets executed whether or not an
// exception was thrown in try block
}
try {
statements;
} catch (exceptionType1 e1) { // one or multiple
statements;
} catch (exceptionType2 e2) {
statements;
}
...
} finally { // one or none
statements;
}
- すべてのTRYステートメントには、1つのCACT句または最終的な条項のいずれかを含める必要があります
- 複数のキャッチ条項を持つことができますが、最終的に句は1つだけです
- 実行中、エラーが発生した場合、コントロールは適切なキャッチブロックに転送され、ステートメントを実行し、最終的にブロックが実行されます。
最終的にブロックが常に実行されていても、一般的に、最終的にブロックが使用されます。セッション、データベース接続またはファイルまたはソケットが開いている場合、それらの接続を閉じるためのコードが配置されます。これは、アプリケーションでメモリリークやその他の問題が発生しないようにするためだけです。
最後に、キャッチブロックはまったく異なります:
キャッチブロック内で、スローされた例外に応答できます。このブロックは、未処理の例外がある場合にのみ実行され、タイプはCatch Blockのパラメーターで指定されたものの1つまたはサブクラスと一致します。最後に、例外が提起されているかどうかにかかわらず、試してみてブロックをキャッチした後、常に実行されます。
TRYは、例外をスローする可能性のあるメソッドを実行するために使用されます
キャッチはその例外を「キャッチ」するために使用されます
最後に、その例外がキャッチされているかどうかに必要なクリーンアップに使用されます
try{
myObject.riskyMethod(); // run a method that may throw an exception
}
catch(Exception ex){
myLogger.log(ex.Message); // "catch" stop that exception
}
finally{
myObject = null; // clean up needed from that exception being caught
}
私の再構築では、最終的にブロックが常に実行され、主に「オープン接続が閉じるために使用され、不必要に実行されているものを破壊するために使用されます。
最後に、ブロックは常に実行されます。キャッチブロックは、ブロックパラメーターに一致する例外がキャッチされた場合にのみ実行されます。
最初のフォームでも、呼び出し方式にログインできます。そのため、すぐに特別な取り扱いをしたくない限り、大きな利点はありません。
一般に、ストリーム、接続などのリソースを使用する場合は、最終的にブロックを使用して明示的に閉じる必要があります。以下のプログラムでは、FileReaderを使用してファイルからデータを読み取り、最終的にブロックを使用して閉じています。
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
public class ReadData_Demo {
public static void main(String args[]){
FileReader fr=null;
try{
File file=new File("file.txt");
fr = new FileReader(file); char [] a = new char[50];
fr.read(a); // reads the content to the array
for(char c : a)
System.out.print(c); //prints the characters one by one
}catch(IOException e){
e.printStackTrace();
}
finally{
try{
fr.close();
}catch(IOException ex){
ex.printStackTrace();
}
}
}
}
たぶん私のような他の人はこのようなものを探していました。
このページからの情報 チュートポイント
Try Blockは、例外を提起する声明を保持します。キャッチブロックは、Tryブロックからスローされた参照を保持し、必要なメッセージはCatchブロックから生成されます。最後にブロックは、IOクロージング、ファイルクロージング、DBクロージングなどの使用済みリソースを閉じるためにも使用されます。必須です