序文
Javaを学ぶ過程で、誰もが例外について章を学んだと思います。ここで例外の基本的な特性と使用については話しません。例外とは何ですか？誰もがそれをどのように理解しているのかわかりません。私の理解は非常に単純です。つまり、異常な状況です。たとえば、私は今男性ですが、女性にユニークなものがあります。私の意見では、これは間違いなく異常であり、私はそれに耐えることができません。誰もがそれを正しく理解し、使用できると思います。
ただし、光学的な基本的な例外処理と使用が不十分な場合、仕事で発生するのは怖くありません。例外を使用してビジネスの処理を促進する必要がある場合があります。たとえば、一意の制約を備えたデータベースを使用する場合、複製データが挿入された場合、一意の制約例外DuplicateKeyExceptionをキャプチャすることで処理できます。この時点で、対応する状態はサーバーレイヤーの呼び出し層にスローでき、上層層は対応する状態に従って処理します。したがって、例外がビジネスのための推進方法である場合があります。
一部の人々は、例外をキャッチした後、例外を出力します。慎重な学生が何かに気づいたのだろうか。出力の例外は何ですか？
一般的な例外は次のとおりです。
java.lang.arithmeticexception： / by zero at greenhouse.exceptestest.testexception（Exceptiontest.java:16）at Sun.reflect.nativemethodacsessorimpl.invoke0（ネイティブ方法） sun.Reflect.DELEGATINGMETHODACSERIMPL.INVOKE（DelegatingMethodaccessorimpl.java:25）at java.lang.reflt.method.invoke（Method.java:597）at org.junit.runners.model.model.modeld.methed. $ 1.runrefflffivecall（ org.junit.internal.runners.model.relectivecallable.run（refrectivecallable.java:15）at org.junit.runners.model.frameworkmethod.invokeexplosively（frameworkmethod.java:41） org.junit.internal.runners.statements.invokemethod.evaluate（invokemethod.java:20）at org.junit.runners.blockjunit4classrunner.runchild（blockjunit4classrunner.java:76）at org.junit.runners.blockjunit4classrunner.runchild（blockjunit4classrunner.java:50）at org.junit.runners.parentrunner $ 3.run.java:193）at org.junit.runner.runner.parentrunner.parentrunner. org.junit.runner.runchildren.runchildren（parentrunner.java:191）at org.junit.runners.parentrunner.Access $ 000（parentrunner.java:42）at org.junit.runners.runners.parentrunner $ 2.Evalute（Parentrunner.Java:184） org.junit.junit.runner.junitcore.run（junitcore.java:157）のorg.junit.runner.junitcore.run（parentrunner.java:236）at com.intellij.junit4.junit4.junit4.junit4ideatestrunner.startrunnerwithrunner.jva） com.intellij.execution.junit.ideatestrunner $ repeater.startrunnerwithargs（ideatestrunner.java:47）at com.intellij.rt.execution.junit.junitstarter.preparestreamsandstart（junitster.java:242）at com.intellij.rt.execution.junit.junitstarter.main（junitstarter.java:70）
ヌルポインターの例外：
java.lang.nullpointerexception at greenhouse.exceptest.testexception（ExceptionTest.java:16）at sun.reflect.nativemethodacsessorimpl.invoke0（native method）at sun.reflect.nativemethodaccessorimpl.invoke sun.Reflect.DELEGATINGMETHODACSERIMPL.INVOKE（DelegatingMethodaccessorimpl.java:25）at java.lang.reflt.method.invoke（Method.java:597）at org.junit.runners.model.model.modeld.methed. $ 1.runrefflffivecall（ org.junit.internal.runners.model.relectivecallable.run（refrectivecallable.java:15）at org.junit.runners.model.frameworkmethod.invokeexplosively（frameworkmethod.java:41） org.junit.internal.runners.statements.invokemethod.evaluate（invokemethod.java:20）at org.junit.runners.blockjunit4classrunner.runchild（blockjunit4classrunner.java:76）at org.junit.runners.blockjunit4classrunner.runchild（blockjunit4classrunner.java:50）at org.junit.runners.parentrunner $ 3.run.java:193）at org.junit.runner.runner.parentrunner.parentrunner. org.junit.runner.runchildren.runchildren（parentrunner.java:191）at org.junit.runners.parentrunner.Access $ 000（parentrunner.java:42）at org.junit.runners.runners.parentrunner $ 2.Evalute（Parentrunner.Java:184） org.junit.junit.runner.junitcore.run（junitcore.java:157）のorg.junit.runner.junitcore.run（parentrunner.java:236）at com.intellij.junit4.junit4.junit4.junit4ideatestrunner.startrunnerwithrunner.jva） com.intellij.execution.junit.ideatestrunner $ repeater.startrunnerwithargs（ideatestrunner.java:47）at com.intellij.rt.execution.junit.junitstarter.preparestreamsandstart（junitster.java:242）at com.intellij.rt.execution.junit.junitstarter.main（junitstarter.java:70）
例外の出力は、例外が正確に発生する場所であり、多くの実行プロセス呼び出しが後で印刷されるという機能を見つけましたか？この情報はどこから来ていますか？この情報はスタックから取得されます。例外ログを印刷するとき、この呼び出し情報はスタックから取得されます。もちろん、例外を正確に見つけることができるのは良いことですが、プログラムのパフォーマンスといくつかの要件を考慮すると、この情報を完全に印刷して、パフォーマンス消費であるメソッドコールスタックから対応する情報を取得する必要がない場合があります。高いパフォーマンス要件を持つ一部のプログラムでは、この側面でプログラムのパフォーマンスを完全に改善できます。
では、これらのスタック情報の出力を避ける方法は？その後、カスタム例外はこの問題を解決できます。
まず、自動例外では、runtimeexceptionを継承し、fillinstacktraceおよびtostringメソッドを書き直す必要があります。たとえば、以下にAppExceptionの例外を定義します。
パッケージcom.green.monitor.common.exception; import java.text.messageformat;/***カスタム例外クラス*/public class appexceptionはruntimeexceptionを拡張します{private boolean issuccess = false;プライベート文字列キー。プライベート文字列情報; public appexception（string key）{super（key）; this.key = key; this.info = key; } public appException（String key、string message）{super（messageformat.format（ "{0} [{1}]、key、message））; this.key = key; this.info = message; } public appException（string message、string key、string info）{super（message）; this.key = key; this.info = info; } public boolean success（）{return issuccess; } public string getKey（）{return key; } public void setKey（string key）{this.key = key; } public string getInfo（）{return info; } public void setinfo（string info）{this.info = info; } @Override public throwable fillinstacktrace（）{return this; } @Override public String toString（）{return messageformat.format（ "{0} [{1}]"、this.key、this.info）; }}では、なぜFillinStackTraceとToString Methodを書き直すのでしょうか？まず、ソースコードが何であるかを見てみましょう。
パブリッククラスruntimeexceptionは例外を拡張します{static final long serialversionuid = -7034897190745766939l; /** <code> null </code>を使用して新しいランタイム例外をその*詳細メッセージとして構築します。原因は初期化されず、その後{@link #initcause}への呼び出しによって *初期化される場合があります。 */ public runtimeexception（）{super（）; } /**指定された詳細メッセージを使用して、新しいランタイム例外を構築します。 *原因は初期化されず、{@link #initcause}への呼び出しによって初期化される場合があります。 * * @paramメッセージ詳細メッセージ。詳細メッセージは、{@link #getMessage（）}メソッドによって *後で取得するために保存されます。 */ public runtimeexception（string message）{super（message）; } /** *指定された詳細メッセージと *原因を使用して、新しいランタイム例外を構築します。 <p> * <code>原因</code>に関連付けられている詳細なメッセージは、<i> </i> </i>は *このランタイム例外の詳細メッセージに自動的に組み込まれていないことに注意してください。 * * @paramメッセージ詳細メッセージ（{@link #getmessage（）}メソッドによって後で取得するために保存されます *）。 * @param原因原因（ * {@link #getCause（）}メソッドによって後で検索するために保存されます）。 （a <tt> null </ tt>値は *許可されており、原因が存在しないか *不明であることを示します。） }/**構築指定された原因と<tt>（cause == null：null：cause.toString（））</tt> *の詳細メッセージを使用した新しいランタイム例外。このコンストラクターは、ランタイムの例外 *に役立ちます *他のスローアブルのラッパーにすぎません。 * * @param原因の原因（ * {@link #getCause（）}メソッドによって後で検索するために保存されます）。 （a <tt> null </ tt>値は *許可されており、原因が存在しないか *不明であることを示します。） }}runtimeexceptionは例外を継承しますが、親クラスメソッドのみを呼び出し、他の操作を行いません。それでは、例外として何が起こっているのかを引き続き見てみましょう。
パブリッククラスの例外拡張可能な{static final long serialversionuid = -3387516993124229948l; /***詳細メッセージとして<code> null </code>を使用して新しい例外を構築します。 *原因は初期化されず、その後{@link #initcause}への呼び出しによって初期化される場合があります。 */ public Except（）{super（）; } /***指定された詳細メッセージを使用して新しい例外を構築します。 *原因は初期化されず、その後 * {@link #initcause}への呼び出しによって初期化される場合があります。 * * @paramメッセージ詳細メッセージ。詳細メッセージは、{@link #getMessage（）}メソッドによって *後で取得するために保存されます。 */ public Exception（string message）{super（message）; } /** *指定された詳細メッセージと *原因で新しい例外を構築します。 <p> * <code>原因</code>に関連付けられている詳細なメッセージは、<i> </i> </i>は、この例外の詳細メッセージに自動的に組み込まれていないことに注意してください。 * * @paramメッセージ詳細メッセージ（{@link #getmessage（）}メソッドによって後で取得するために保存されます *）。 * @param原因原因（ * {@link #getCause（）}メソッドによって後で検索するために保存されます）。 （a <tt> null </ tt>値は *許可されており、原因が存在しないか *不明であることを示します。） }/** *指定された原因と詳細 * <tt>（cause == null：null：cause.toString（））</tt>の詳細メッセージを作成します（通常、<tt>原因</tt>のクラスと詳細メッセージが含まれています）。 *このコンストラクターは、他のスローアブルのラッパーにすぎない例外に役立ちます（たとえば、{@link * java.security.privilededactionexception}）。 * * @param原因の原因（ * {@link #getCause（）}メソッドによって後で検索するために保存されます）。 （a <tt> null </ tt>値は *許可されており、原因が存在しないか *不明であることを示します。） }}ソースコードからわかるように、親クラスの方法は、例外として直接呼び出されます。 runtimeexceptionのように、私は実際に何もしませんでした。それでは、スロー可能なことで何が起こっているのか見てみましょう。
public class throwableはserializable {public throwable（string message）{fillinstacktrace（）; detailmessage = message; } /***実行スタックトレースを埋めます。このメソッドは、現在のスレッドのスタックフレームの現在の状態に関するこの * <code>スロー可能な</code>オブジェクト情報内に記録されます。 * * @returnこの<code> throwable </code>インスタンスへの参照。 * @see java.lang.throwable＃printstacktrace（） */ public synchronized nativeable throwable fillinstacktrace（）; /** * * {@link #printstacktrace（）}によって印刷されたスタックトレース情報へのプログラミングアクセスを提供します。スタックトレース要素の配列を返します *それぞれ1つのスタックフレームを表します。配列 *のゼロス要素（配列の長さがゼロではないと仮定）は、 *スタックの上部を表します。これは、シーケンスの最後のメソッド呼び出しです。通常、 *これはこの投げ可能なポイントが作成され、投げられたポイントです。 *配列の最後の要素（配列の長さがゼロではないと仮定） *スタックの下部を表します。これは、シーケンス内の最初のメソッド呼び出し *です。 * * <p>いくつかの仮想マシンは、状況によっては、スタックトレースから1つ以上のスタックフレームを省略する場合があります。極端な場合、 *このスローブルに関するスタックトレース情報がない仮想マシンは、この *メソッドからゼロ長いアレイを返すことができます。一般的に、この方法で返される配列には、 * printStacktrace </tt>によって印刷されるすべてのフレームに1つの要素が含まれます。 * * @Returnこのスロー可能なスタックトレースを表すスタックトレース要素の配列。 * @since 1.4 */ public stacktraceElement [] getStackTrace（）{return（stacktraceElement []）getourstacktrace（）。clone（）; } private synchronized stacktraceElement [] getourstacktrace（）{//スタックトレースを初期化した場合、これがこのメソッドの最初の呼び出しである場合、（stacktrace == null）{int dept = getStackTraceDepth（）; stacktrace = new StackTraceElement [深さ]; for（int i = 0; i <depth; i ++）stacktrace [i] = getStackTraceElement（i）; } stacktraceを返します。 } /** *スタックトレース内の要素の数を返します（またはスタック *トレースが利用できない場合は0）。 * * SharedSecretsによる使用のためのパッケージ保護。 */ native int getStackTraceDepth（）; /***スタックトレースの指定された要素を返します。 * * SharedSecretsによる使用のためのパッケージ保護。 * * @paramインデックス要素のインデックスを返す。 * @throws indexoutofboundsexception if <tt> index <0 || * index> = getStackTraceDepth（）</ tt> */ native stacktraceElement getStackTraceElement（int index）; /***このスロー可能な説明を返します。 *結果は、： * <ul> * <li>このオブジェクトのクラスの{@linkplainクラス＃getname（）name}の連結 * <li> "："（コロンとスペース） * <li>このオブジェクトの呼び出し{@link #getlocalizedmessage} * <tt> null </tt>、次に *クラス名が返されます。 * * @returnこのスロー可能な文字列表現。 */ public string toString（）{string s = getClass（）。getName（）;文字列メッセージ= getLocalizedMessage（）; return（message！= null）？ （s + "：" +メッセージ）：s; }ソースコードから、スロー可能な終了がほぼ終了します。 fillinstacktrace（）メソッドはネイティブメソッドです。この方法では、基礎となるC言語を呼び出し、投げられるオブジェクト、ToStringメソッドを返し、スロー可能な説明を返します。 GetStackTraceメソッドとGetourStackTraceでは、ネイティブメソッドGetStackTraceElementが呼び出されます。このメソッドは、指定されたスタック要素情報を返すため、このプロセスはパフォーマンスを消費する必要があります。次に、カスタム例外でToStringメソッドとFillinStackTraceメソッドを書き換えて、スタックから例外情報を取得せずに直接出力できます。これは、システムとプログラムにとって「重い」ものではなく、パフォーマンスを最適化する非常に良い方法です。では、カスタム例外が発生した場合、どのように見えますか？以下をご覧ください：
@test public void testexception（）{try {string str = null; System.out.println（str.Charat（0））; } catch（Exception e）{throw new AppException（ "000001"、 "Null Pointer Exception"）; }}次に、例外が異常な場合、システムはカスタマイズされた例外情報を印刷します。
000001 [null pointer Exception]出口コード-1で完了しました
したがって、それは特に簡潔でシステムプログラムのパフォーマンスを最適化し、プログラムの「重い」ものを減らすため、特別なパフォーマンス要件を持つシステムが必要です。急いで独自の例外をカスタマイズしてください！
要約します
上記は、この記事のコンテンツ全体です。この記事の内容には、すべての人の研究や仕事に特定の参照値があることを願っています。ご質問がある場合は、メッセージを残してコミュニケーションをとることができます。 wulin.comへのご支援ありがとうございます。