データベースとの接続を確立したいコンストラクターでDBクラスを構築しているので、そのクラス内の残りの関数から静的dbLinkにアクセスできます。それは良いアプローチですか？
質問する
796 次
4 に答える
12
具体的な質問に関しては、コンストラクターで例外をスローすることは確かに合法です。「DBクラス」インスタンスが切断された接続で使用されるのを防ぐ他の正しい方法はありません。
具体的な機能要件に関しては、もう1つの大きな問題があります。「DBクラス」のコンストラクターでDB接続を作成するべきではなく、確実に作成しないでstaticください。これは、「DBクラス」のインスタンスがJavaのメモリに存在する限り、接続を開いたままにするつもりであることを示しています。これは非常に悪い考えです。try代わりに、SQLクエリ/クエリを実行している場所とまったく同じブロックに接続を作成する必要があります。finallyそのブロックで接続も閉じる必要がありますtryブロック。これにより、長期間開いているためにDBサーバーがリソースをタイムアウトしたり、開いている接続が多すぎるためにリソースが不足したりして、アプリケーションがクラッシュする原因となるリソースリークを長期間防ぐことができます。
参照：
于 2012-04-05T20:38:33.853 に答える
3
私の提案は、connect()例外をスローし、例外なしでクラスをインスタンス化できるメソッドをクラスに提供することです。
于 2012-04-05T20:40:22.997 に答える
2
「こんにちは、はい、コンストラクターから例外をスローするのは正常です。実際、コンストラクターが失敗する唯一の方法は例外をスローすることです。
ただし、RuntimeExceptionのサブクラスであるコンストラクターから例外をスローする場合は注意が必要です。Javaコンパイラは、呼び出し元のコードにそのような例外の処理を強制しないため、追加のリスクが発生します。たまに使っても大丈夫ですが、気をつけてください。」
ここから： http： //en.allexperts.com/q/Java-1046/normal-throw-exception-constructor.htm
于 2012-04-05T20:32:05.750 に答える
1
通常、ある種の接続オブジェクトを作成しても、実際には接続が確立されるのではなく、確立される接続が設定されるだけです。connect()接続を確立するか、接続できない場合は例外をスローするメソッドを使用する方が理にかなっています。
コンストラクターに接続を確立させることは意味がないと思うので、例外をスローするべきではありません。
于 2012-04-05T20:37:01.133 に答える