C Sharpの基礎 - 例外処理 - 版の履歴

2021年6月5日 (土) 13:18にWikiによる

2021-06-05T13:18:29Z

← 古い版		2021年6月5日 (土) 22:18時点における版
31行目:		31行目:
	* 全ての例外クラスはシリアル化可能であるべきである。		* 全ての例外クラスはシリアル化可能であるべきである。
	*: 以下のような場合、例外クラスをシリアル化する必要がある。		*: 以下のような場合、例外クラスをシリアル化する必要がある。
	** ソフトウェアの実行中にスローされた例外オブジェクトが、ソフトウェアドメインの境界を越える場合		: ソフトウェアの実行中にスローされた例外オブジェクトが、ソフトウェアドメインの境界を越える場合
	** 例外の内容をログに出力する場合		: 例外の内容をログに出力する場合
			*: <br>
	*: 上記のようなシーンにおいて、例外クラスを使用しない場合もあるが、		*: 上記のようなシーンにおいて、例外クラスを使用しない場合もあるが、
	*: シリアル化の対応は簡単に行うことができるため、対応することにより、例外クラスの堅牢性が増す。		*: シリアル化の対応は簡単に行うことができるため、対応することにより、例外クラスの堅牢性が増す。
	~~<br>~~<br>		<br>
			==== シリアル化とは ====
	== シリアル化とは ==
	シリアル化とは、オブジェクトをバイトストリームに変換する処理のことである。<br>		シリアル化とは、オブジェクトをバイトストリームに変換する処理のことである。<br>
	オブジェクトの現在の状態をファイルに書き出すような処理を行う。<br>		オブジェクトの現在の状態をファイルに書き出すような処理を行う。<br>
47行目:		47行目:
	また、シリアル化されたバイトストリームを元のオブジェクトに戻す処理のことを、逆シリアル化と呼ぶ。<br>		また、シリアル化されたバイトストリームを元のオブジェクトに戻す処理のことを、逆シリアル化と呼ぶ。<br>
	[https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/serialization/ シリアル化 (C#) \| Microsoft Docs]<br>		[https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/serialization/ シリアル化 (C#) \| Microsoft Docs]<br>
	<br>~~<br>~~		<br>

	==== 例外クラスの作成 ====		==== 例外クラスの作成 ====
	以下の例では、例外クラスを作成している。<br>		以下の例では、例外クラスを作成している。<br>
60行目:		59行目:
	*: <br>		*: <br>
	* 例外クラスのシリアル化対応		* 例外クラスのシリアル化対応
	*: <code>SerializableAttribute</code>属性と4番目のコンストラクタにより、例外クラスは、ソフトウェアのドメイン境界を越えることができる。~~<br>~~		*: <code>SerializableAttribute</code>属性と4番目のコンストラクタにより、例外クラスは、ソフトウェアのドメイン境界を越えることができる。
	*: <code>SerializableAttribute</code>属性がある全てのクラスは、フォーマッタを使用してシリアル化が可能になる。~~<br>~~		*: <code>SerializableAttribute</code>属性がある全てのクラスは、フォーマッタを使用してシリアル化が可能になる。
	*: 特に、例外クラスに<code>SerializableAttribute</code>属性がある場合、例外がソフトウェアのドメイン境界を超える時、必要に応じて自動的にシリアル化を行う。~~<br>~~		*: 特に、例外クラスに<code>SerializableAttribute</code>属性がある場合、例外がソフトウェアのドメイン境界を超える時、必要に応じて自動的にシリアル化を行う。
	*: <br>		*: <br>
	*: シリアル化されて、別のソフトウェアのドメインからスローされた例外オブジェクトを正しく受け取るためには、元の例外オブジェクトに戻す必要がある。		*: シリアル化されて、別のソフトウェアのドメインからスローされた例外オブジェクトを正しく受け取るためには、元の例外オブジェクトに戻す必要がある。
	*: これを、逆シリアル化と呼ぶ。~~<br>~~		*: これを、逆シリアル化と呼ぶ。
	*: これを行うのが、4番目のコンストラクタとなる。~~<br>~~		*: これを行うのが、4番目のコンストラクタとなる。
	*: <br>		*: <br>
	*: 4番目のコンストラクタは、フォーマッタが呼び出すために存在するため、設計者が明示的に呼び出すことはない。~~<br>~~		*: 4番目のコンストラクタは、フォーマッタが呼び出すために存在するため、設計者が明示的に呼び出すことはない。
	*: また、呼び出されることを避けるため、<code>protected</code>修飾子を付加する。(フォーマッタは、アクセス修飾子に関係なく呼び出すことができる)~~<br>~~		*: また、呼び出されることを避けるため、<code>protected</code>修飾子を付加する。(フォーマッタは、アクセス修飾子に関係なく呼び出すことができる)
	*: <br>		*: <br>
	*: 逆シリアル化コンストラクタが<code>public</code>修飾子の場合、任意のコードから不正なデータを渡して例外クラスのインスタンスを生成できる。~~<br>~~		*: 逆シリアル化コンストラクタが<code>public</code>修飾子の場合、任意のコードから不正なデータを渡して例外クラスのインスタンスを生成できる。
	*: また、例外クラスの継承を禁止する(<code>sealed</code>修飾子を付加する)場合は、逆シリアル化コンストラクタに<code>private</code>修飾子を付加することもできる。~~<br>~~		*: また、例外クラスの継承を禁止する(<code>sealed</code>修飾子を付加する)場合は、逆シリアル化コンストラクタに<code>private</code>修飾子を付加することもできる。
	<syntaxhighlight lang="c#">		<syntaxhighlight lang="c#">
	using System;		using System;

Wiki: /* 例外クラスの設計方針 */

2021-06-05T13:14:28Z

例外クラスの設計方針

← 古い版		2021年6月5日 (土) 22:14時点における版
35行目:		35行目:
	*: 上記のようなシーンにおいて、例外クラスを使用しない場合もあるが、		*: 上記のようなシーンにおいて、例外クラスを使用しない場合もあるが、
	*: シリアル化の対応は簡単に行うことができるため、対応することにより、例外クラスの堅牢性が増す。		*: シリアル化の対応は簡単に行うことができるため、対応することにより、例外クラスの堅牢性が増す。
	<br>		<br><br>

			== シリアル化とは ==
	シリアル化とは、オブジェクトをバイトストリームに変換する処理のことである。<br>		シリアル化とは、オブジェクトをバイトストリームに変換する処理のことである。<br>
	オブジェクトの現在の状態をファイルに書き出すような処理を行う。<br>		オブジェクトの現在の状態をファイルに書き出すような処理を行う。<br>
45行目:		47行目:
	また、シリアル化されたバイトストリームを元のオブジェクトに戻す処理のことを、逆シリアル化と呼ぶ。<br>		また、シリアル化されたバイトストリームを元のオブジェクトに戻す処理のことを、逆シリアル化と呼ぶ。<br>
	[https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/serialization/ シリアル化 (C#) \| Microsoft Docs]<br>		[https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/serialization/ シリアル化 (C#) \| Microsoft Docs]<br>
	<br>		<br><br>

	==== 例外クラスの作成 ====		==== 例外クラスの作成 ====

Wiki: /* 例外クラスの作成 */

2021-06-05T13:04:27Z

例外クラスの作成

← 古い版		2021年6月5日 (土) 22:04時点における版
49行目:		49行目:
	==== 例外クラスの作成 ====		==== 例外クラスの作成 ====
	以下の例では、例外クラスを作成している。<br>		以下の例では、例外クラスを作成している。<br>
			例外クラスは、<code>System.Exception</code>クラスを継承して作成する。<br>
	<br>		<br>
	~~例外クラスは、<code>System.Exception</code>クラスを継承する。<br>~~		以下の例のように、4つのコンストラクタは、与えられた引数を基底クラス(<code>System.Exception</code>クラス)のコンストラクタに渡す。<br>
	~~4つのコンストラクタは、与えられた引数を基底クラス~~(<code>System.Exception</code>クラス)のコンストラクタに渡す。<br>
	<br>		<br>
	3番目のコンストラクタは、例外メッセージと共に、例外の原因となる別の例外への参照を<code>innerException</code>に設定して、~~<br>~~		* 基本の3つのコンストラクタを実装
	例外クラスのインスタンスを初期化するためのものである。<br>		*: 3番目のコンストラクタは、例外メッセージと共に、例外の原因となる別の例外への参照を<code>innerException</code>に設定して、
	~~<br>~~		*: 例外クラスのインスタンスを初期化するためのものである。
	<code>SerializableAttribute</code>属性と4番目のコンストラクタにより、例外クラスは、ソフトウェアのドメイン境界を越えることができる。<br>		*: <br>
	<code>SerializableAttribute</code>属性がある全てのクラスは、フォーマッタを使用してシリアル化が可能になる。<br>		* 例外クラスのシリアル化対応
	特に、例外クラスに<code>SerializableAttribute</code>属性がある場合、例外がソフトウェアのドメイン境界を超える時、必要に応じて自動的にシリアル化を行う。<br>		*: <code>SerializableAttribute</code>属性と4番目のコンストラクタにより、例外クラスは、ソフトウェアのドメイン境界を越えることができる。<br>
	<br>		*: <code>SerializableAttribute</code>属性がある全てのクラスは、フォーマッタを使用してシリアル化が可能になる。<br>
	~~シリアル化されて、別のソフトウェアのドメインからスローされた例外オブジェクトを正しく受け取るためには、<br>~~		*: 特に、例外クラスに<code>SerializableAttribute</code>属性がある場合、例外がソフトウェアのドメイン境界を超える時、必要に応じて自動的にシリアル化を行う。<br>
	~~元の例外オブジェクトに戻す必要がある。これを、逆シリアル化と呼ぶ。~~<br>		*: <br>
	これを行うのが、4番目のコンストラクタとなる。<br>		*: シリアル化されて、別のソフトウェアのドメインからスローされた例外オブジェクトを正しく受け取るためには、元の例外オブジェクトに戻す必要がある。
	<br>		*: これを、逆シリアル化と呼ぶ。<br>
	4番目のコンストラクタは、フォーマッタが呼び出すために存在するため、設計者が明示的に呼び出すことはない。<br>		*: これを行うのが、4番目のコンストラクタとなる。<br>
	また、呼び出されることを避けるため、<code>protected</code>修飾子を付加する。(フォーマッタは、アクセス修飾子に関係なく呼び出すことができる)<br>		*: <br>
	<br>		*: 4番目のコンストラクタは、フォーマッタが呼び出すために存在するため、設計者が明示的に呼び出すことはない。<br>
	逆シリアル化コンストラクタが<code>public</code>修飾子の場合、任意のコードから不正なデータを渡して例外クラスのインスタンスを生成できる。<br>		*: また、呼び出されることを避けるため、<code>protected</code>修飾子を付加する。(フォーマッタは、アクセス修飾子に関係なく呼び出すことができる)<br>
	~~また、例外クラスを継承禁止にする~~(<code>sealed</code>修飾子を付加する)場合は、逆シリアル化コンストラクタに<code>private</code>修飾子を付加することもできる。<br>		*: <br>
			*: 逆シリアル化コンストラクタが<code>public</code>修飾子の場合、任意のコードから不正なデータを渡して例外クラスのインスタンスを生成できる。<br>
			*: また、例外クラスの継承を禁止する(<code>sealed</code>修飾子を付加する)場合は、逆シリアル化コンストラクタに<code>private</code>修飾子を付加することもできる。<br>
	<syntaxhighlight lang="c#">		<syntaxhighlight lang="c#">
	using System;		using System;

Wiki: /* 例外クラスの作成 */

2021-03-26T15:55:25Z

例外クラスの作成

← 古い版		2021年3月27日 (土) 00:55時点における版
50行目:		50行目:
	以下の例では、例外クラスを作成している。<br>		以下の例では、例外クラスを作成している。<br>
	<br>		<br>
	~~例外クラスは、System~~.~~Exceptionクラスを継承する。~~<br>		例外クラスは、<code>System.Exception</code>クラスを継承する。<br>
	4つのコンストラクタは、与えられた引数を基底クラス(System.~~Exceptionクラス~~)のコンストラクタに渡す。<br>		4つのコンストラクタは、与えられた引数を基底クラス(<code>System.Exception</code>クラス)のコンストラクタに渡す。<br>
	<br>		<br>
	~~3番目のコンストラクタは、例外メッセージと共に、例外の原因となる別の例外への参照をinnerExceptionに設定して、~~<br>		3番目のコンストラクタは、例外メッセージと共に、例外の原因となる別の例外への参照を<code>innerException</code>に設定して、<br>
	例外クラスのインスタンスを初期化するためのものである。<br>		例外クラスのインスタンスを初期化するためのものである。<br>
	<br>		<br>
	~~SerializableAttribute属性と4番目のコンストラクタにより、例外クラスは、ソフトウェアのドメイン境界を越えることができる。~~<br>		<code>SerializableAttribute</code>属性と4番目のコンストラクタにより、例外クラスは、ソフトウェアのドメイン境界を越えることができる。<br>
	~~SerializableAttribute属性がある全てのクラスは、フォーマッタを使用してシリアル化が可能になる。~~<br>		<code>SerializableAttribute</code>属性がある全てのクラスは、フォーマッタを使用してシリアル化が可能になる。<br>
	~~特に、例外クラスにSerializableAttribute属性がある場合、例外がソフトウェアのドメイン境界を超える時、必要に応じて自動的にシリアル化を行う。~~<br>		特に、例外クラスに<code>SerializableAttribute</code>属性がある場合、例外がソフトウェアのドメイン境界を超える時、必要に応じて自動的にシリアル化を行う。<br>
	<br>		<br>
	シリアル化されて、別のソフトウェアのドメインからスローされた例外オブジェクトを正しく受け取るためには、<br>		シリアル化されて、別のソフトウェアのドメインからスローされた例外オブジェクトを正しく受け取るためには、<br>
65行目:		65行目:
	<br>		<br>
	4番目のコンストラクタは、フォーマッタが呼び出すために存在するため、設計者が明示的に呼び出すことはない。<br>		4番目のコンストラクタは、フォーマッタが呼び出すために存在するため、設計者が明示的に呼び出すことはない。<br>
	~~呼び出されると困るため、アクセス修飾子をprotectedに設定する。~~(フォーマッタは、アクセス修飾子に関係なく呼び出すことができる)<br>		また、呼び出されることを避けるため、<code>protected</code>修飾子を付加する。(フォーマッタは、アクセス修飾子に関係なく呼び出すことができる)<br>
			<br>
			逆シリアル化コンストラクタが<code>public</code>修飾子の場合、任意のコードから不正なデータを渡して例外クラスのインスタンスを生成できる。<br>
			また、例外クラスを継承禁止にする(<code>sealed</code>修飾子を付加する)場合は、逆シリアル化コンストラクタに<code>private</code>修飾子を付加することもできる。<br>
	<syntaxhighlight lang="c#">		<syntaxhighlight lang="c#">
	using System;		using System;

Wiki: /* 例外クラスの設計方針 */

2021-03-26T15:49:59Z

例外クラスの設計方針

← 古い版		2021年3月27日 (土) 00:49時点における版
19行目:		19行目:
	*: <br>		*: <br>
	* 全ての例外クラスは、System.Exceptionを継承する。		* 全ての例外クラスは、System.Exceptionを継承する。
	*: C#では、System.~~Exceptionクラスの派生クラスのみをスローすることができる。※1~~		*: C#では、System.Exceptionクラスの派生クラスのみをスローすることができる。
			*: <br>
			*: Exceptionクラスから派生していないオブジェクトをキャッチすることもできる。
			*: これは、.NET FrameworkのCLRの仕様では、どのようなオブジェクトでもスローすることができるからである。
			*: 他の言語との相互運用することを考慮した結果、C#は任意のオブジェクトをキャッチすることができるようになっている。
	*: <br>		*: <br>
	* 例外クラスの継承階層は、できる限り浅くする。		* 例外クラスの継承階層は、できる限り浅くする。
42行目:		46行目:
	[https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/serialization/ シリアル化 (C#) \| Microsoft Docs]<br>		[https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/serialization/ シリアル化 (C#) \| Microsoft Docs]<br>
	<br>		<br>

	==== 例外クラスの作成 ====		==== 例外クラスの作成 ====
	以下の例では、例外クラスを作成している。<br>		以下の例では、例外クラスを作成している。<br>

Wiki: /* 概要 */

2021-03-26T13:53:11Z

概要

@@ 1行目: / 1行目: @@
 == 概要 ==
-Windowsフォームやコンソールを実装する際、例外が発生する可能性がある個所では、<br>
+例外が発生する可能性がある場所では、Try-Catch構文により、その例外をキャッチして適切な処置を施す必要がある。<br>
-Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。<br>
+<br><br>
 <br><br>

2021年3月26日 (金) 13:15にWikiによる

2021-03-26T13:15:57Z

← 古い版		2021年3月26日 (金) 22:15時点における版
1行目:		1行目:
	== 概要 ==		== 概要 ==
	Windowsフォームやコンソールを実装する際、例外が発生する可能性がある個所では、<br>		Windowsフォームやコンソールを実装する際、例外が発生する可能性がある個所では、<br>
	Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。<br><br>		Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。<br>
	~~しかし、現実には例外が正しくキャッチ~~(トラップ)~~されていないというケースは多々あり、~~<br>		<br><br>
	~~その場合にはアプリケーションの実行中に次のような~~.NET ~~Framework標準のエラーダイアログが表示されてしまうことになる。~~<br>
			== 処理されていない例外をハンドルする ==
			一般的に、例外が正しくキャッチ(トラップ)されていないというケースは多々ある。<br>
			<br>
			その場合、ソフトウェアの実行中において、以下のような.NET Framework標準のエラーダイアログが表示されてしまう。<br>
			このエラーダイアログは、ユーザにとって理解しにくい。<br>
	[[ファイル:Catch exception 01.gif\|フレームなし\|中央]]		[[ファイル:Catch exception 01.gif\|フレームなし\|中央]]
	<br>		<br>
	~~このエラーダイアログは、一般ユーザにとって理解しにくい。PCの操作に自信のない人であれば、これを見た途端に困惑してしまう。<br>~~		これを避けるために、.NET Framework標準のエラーダイアログを、自作のエラーダイアログに切り替えたいという要望も多い。<br>
	~~この事態を避けるために、~~.NET ~~Framework標準のエラーダイアログを、ユーザライクな自作のエラーダイアログに切り替えたいという要望も多い。~~<br><br>		<br>
	~~ここでは、Windowsフォームやコンソールで処理されていない例外を1カ所でまとめてハンドルする方法を記載する。~~<br>		ここでは、処理されていない例外を1ヶ所に纏めてハンドルする方法を記載する。<br>
	この方法により、ハンドルしたメソッド内で独自に作成したエラーダイアログを表示すれば、前述の要望も実現可能である。<br><br>		この方法により、ハンドルしたメソッド内で独自に作成したエラーダイアログを表示すれば、前述の要望も実現可能である。<br>
			<br>
	~~== 処理されていない例外をハンドルするには ==~~		* Application.ThreadExceptionイベントの活用
	* ~~'''~~Application.ThreadExceptionイベントの活用~~'''~~		*: 処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の
	:処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の		*: ThreadExceptionイベントをハンドルして処理する。
	:ThreadExceptionイベントをハンドルして処理する。		*: このイベントは、Windowsフォームのメインスレッド(ApplicationクラスのRunメソッドにより実行されるアプリケーションのコンテキスト)内で
	:このイベントは、Windowsフォームのメインスレッド(ApplicationクラスのRunメソッドにより実行されるアプリケーションのコンテキスト)内で		*: 発生した未処理の例外をハンドルするためのものである。
	:発生した未処理の例外をハンドルするためのものである。		*: <br>
			* Thread.GetDomain().UnhandledExceptionイベントの活用
	* ~~'''~~Thread.GetDomain().UnhandledExceptionイベントの活用~~'''~~		*: では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、
	:では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、		*: 現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の
	:現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の		*: UnhandledExceptionイベントで出来る。
	:UnhandledExceptionイベントで出来る。		*: 例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、
	:例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、		*: 全てこのUnhandledExceptionイベントをハンドルして処理すればよい。
	:全てこのUnhandledExceptionイベントをハンドルして処理すればよい。		<br>
			以下の例では、上記2つのイベントを活用して、未処理の例外を実際に処理している。<br>
	~~上記2つのイベントを活用して未処理の例外を実際に処理しているのが、次のサンプルコードである。~~<br><br>		<syntaxhighlight lang="c#">

	~~== サンプルコード ==~~
	<~~source~~ lang="~~cpp~~">
	using System;		using System;
	using System.Windows.Forms;		using System.Windows.Forms;
79行目:		81行目:
	}		}
	}		}
	</~~source~~>		</syntaxhighlight>
	<br><br>		<br><br>

	__FORCETOC__		__FORCETOC__
	[[カテゴリ:C_Sharp]]		[[カテゴリ:C_Sharp]]

Wiki: Wiki がページ「適切に処理されなかった例外をキャッチする(C Sharp)」を「C Sharpの基礎 - 例外処理」に、リダイレクトを残さずに移動しました

2020-10-21T18:11:41Z

Wiki がページ「適切に処理されなかった例外をキャッチする(C Sharp)」を「C Sharpの基礎 - 例外処理」に、リダイレクトを残さずに移動しました

← 古い版	2020年10月22日 (木) 03:11時点における版
(相違点なし)

Wiki: Wiki がページ「適切に処理されなかった例外をキャッチする」を「適切に処理されなかった例外をキャッチする(C Sharp)」に、リダイレクトを残さずに移動しました

2020-02-04T15:06:14Z

Wiki がページ「適切に処理されなかった例外をキャッチする」を「適切に処理されなかった例外をキャッチする(C Sharp)」に、リダイレクトを残さずに移動しました

← 古い版	2020年2月5日 (水) 00:06時点における版
(相違点なし)

2019年7月8日 (月) 04:38にWikiによる

2019-07-08T04:38:05Z

← 古い版		2019年7月8日 (月) 13:38時点における版
12行目:		12行目:

	== 処理されていない例外をハンドルするには ==		== 処理されていない例外をハンドルするには ==
	'''1. Application.ThreadExceptionイベントの活用'''		* '''Application.ThreadExceptionイベントの活用'''
	処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の~~<br>~~		:処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の
	ThreadExceptionイベントをハンドルして処理する。~~<br>~~		:ThreadExceptionイベントをハンドルして処理する。
	このイベントは、Windowsフォームのメインスレッド(ApplicationクラスのRunメソッドにより実行されるアプリケーションのコンテキスト)内で~~<br>~~		:このイベントは、Windowsフォームのメインスレッド(ApplicationクラスのRunメソッドにより実行されるアプリケーションのコンテキスト)内で
	発生した未処理の例外をハンドルするためのものである。~~<br><br>~~		:発生した未処理の例外をハンドルするためのものである。

	'''2. Thread.GetDomain().UnhandledExceptionイベントの活用'''		* '''Thread.GetDomain().UnhandledExceptionイベントの活用'''
	では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、~~<br>~~		:では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、
	現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の~~<br>~~		:現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の
	UnhandledExceptionイベントで出来る。~~<br>~~		:UnhandledExceptionイベントで出来る。
	例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、~~<br>~~		:例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、
	全てこのUnhandledExceptionイベントをハンドルして処理すればよい。~~<br><br>~~		:全てこのUnhandledExceptionイベントをハンドルして処理すればよい。

	上記2つのイベントを活用して未処理の例外を実際に処理しているのが、次のサンプルコードである。<br><br>		上記2つのイベントを活用して未処理の例外を実際に処理しているのが、次のサンプルコードである。<br><br>

2019年7月8日 (月) 04:35にWikiによる

2019-07-08T04:35:21Z

← 古い版		2019年7月8日 (月) 13:35時点における版
12行目:		12行目:

	== 処理されていない例外をハンドルするには ==		== 処理されていない例外をハンドルするには ==
	# '''Application.ThreadExceptionイベントの活用'''		'''1. Application.ThreadExceptionイベントの活用'''
	処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の<br>		処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の<br>
	ThreadExceptionイベントをハンドルして処理する。<br>		ThreadExceptionイベントをハンドルして処理する。<br>
18行目:		18行目:
	発生した未処理の例外をハンドルするためのものである。<br><br>		発生した未処理の例外をハンドルするためのものである。<br><br>

	# '''Thread.GetDomain().UnhandledExceptionイベントの活用'''		'''2. Thread.GetDomain().UnhandledExceptionイベントの活用'''
	では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、<br>		では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、<br>
	現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の<br>		現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の<br>
	UnhandledExceptionイベントで出来る。<br>~~<br>~~		UnhandledExceptionイベントで出来る。<br>

	例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、<br>		例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、<br>
	全てこのUnhandledExceptionイベントをハンドルして処理すればよい。<br><br>		全てこのUnhandledExceptionイベントをハンドルして処理すればよい。<br><br>

2019年7月8日 (月) 04:34にWikiによる

2019-07-08T04:34:09Z

2019年7月8日 (月) 04:32にWikiによる

2019-07-08T04:32:36Z

@@ 1行目: / 1行目: @@
 == 概要 ==
-Windowsフォームアプリケーションやコンソールアプリケーションを実装する際、例外が発生する可能性がある個所では、
+Windowsフォームやコンソールを実装する際、例外が発生する可能性がある個所では、
-基本的に、Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。
+Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。
 しかし、現実には例外が正しくキャッチ(トラップ)されていないというケースは多々あり、
 その場合にはアプリケーションの実行中に次のような.NET Framework標準のエラーダイアログが表示されてしまうことになる。

192.168.1.23: ページの作成:「== 概要 == Windowsフォームアプリケーションやコンソールアプリケーションを実装する際、例外が発生する可能性がある個所では…」

2019-07-08T04:07:11Z

ページの作成:「== 概要 == Windowsフォームアプリケーションやコンソールアプリケーションを実装する際、例外が発生する可能性がある個所では…」

新規ページ

== 概要 ==
Windowsフォームアプリケーションやコンソールアプリケーションを実装する際、例外が発生する可能性がある個所では、
基本的に、Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。
しかし、現実には例外が正しくキャッチ(トラップ)されていないというケースは多々あり、
その場合にはアプリケーションの実行中に次のような.NET Framework標準のエラーダイアログが表示されてしまうことになる。

← 古い版		2019年7月8日 (月) 13:34時点における版
1行目:		1行目:
	== 概要 ==		== 概要 ==
	Windowsフォームやコンソールを実装する際、例外が発生する可能性がある個所では、		Windowsフォームやコンソールを実装する際、例外が発生する可能性がある個所では、<br>
	Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。		Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。<br><br>
	しかし、現実には例外が正しくキャッチ(トラップ)されていないというケースは多々あり、		しかし、現実には例外が正しくキャッチ(トラップ)されていないというケースは多々あり、<br>
	その場合にはアプリケーションの実行中に次のような.NET Framework標準のエラーダイアログが表示されてしまうことになる。		その場合にはアプリケーションの実行中に次のような.NET Framework標準のエラーダイアログが表示されてしまうことになる。<br>
	[[ファイル:Catch exception 01.gif\|フレームなし\|中央]]		[[ファイル:Catch exception 01.gif\|フレームなし\|中央]]
			<br>
	このエラーダイアログは、一般ユーザにとって理解しにくい。PCの操作に自信のない人であれば、これを見た途端に困惑してしまう。		このエラーダイアログは、一般ユーザにとって理解しにくい。PCの操作に自信のない人であれば、これを見た途端に困惑してしまう。<br>
	この事態を避けるために、.NET Framework標準のエラーダイアログを、ユーザライクな自作のエラーダイアログに切り替えたいという要望も多い。		この事態を避けるために、.NET Framework標準のエラーダイアログを、ユーザライクな自作のエラーダイアログに切り替えたいという要望も多い。<br><br>
			ここでは、Windowsフォームやコンソールで処理されていない例外を1カ所でまとめてハンドルする方法を記載する。<br>
	ここでは、Windowsフォームやコンソールで処理されていない例外を1カ所でまとめてハンドルする方法を記載する。		この方法により、ハンドルしたメソッド内で独自に作成したエラーダイアログを表示すれば、前述の要望も実現可能である。<br><br>
	この方法により、ハンドルしたメソッド内で独自に作成したエラーダイアログを表示すれば、前述の要望も実現可能である。

	== 処理されていない例外をハンドルするには ==		== 処理されていない例外をハンドルするには ==
	# '''Application.ThreadExceptionイベントの活用'''		# '''Application.ThreadExceptionイベントの活用'''
	処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の		処理されなかった例外をハンドルするには、WindowsフォームならApplicationクラス(System.Windows.Forms名前空間)の<br>
	ThreadExceptionイベントをハンドルして処理する。		ThreadExceptionイベントをハンドルして処理する。<br>
	このイベントは、Windowsフォームのメインスレッド(ApplicationクラスのRunメソッドにより実行されるアプリケーションのコンテキスト)内で		このイベントは、Windowsフォームのメインスレッド(ApplicationクラスのRunメソッドにより実行されるアプリケーションのコンテキスト)内で<br>
	発生した未処理の例外をハンドルするためのものである。		発生した未処理の例外をハンドルするためのものである。<br><br>

	# '''Thread.GetDomain().UnhandledExceptionイベントの活用'''		# '''Thread.GetDomain().UnhandledExceptionイベントの活用'''
	では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、		では、上記のメイン・スレッド以外のコンテキスト上で発生した例外は、<br>
	現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の		現在のアプリケーションドメイン(AppDomainクラス(System名前空間)のThread.GetDomainメソッドにより取得できる)の<br>
	UnhandledExceptionイベントで出来る。		UnhandledExceptionイベントで出来る。<br><br>

	例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、		例えば、マルチスレッド処理において、メインスレッド以外のスレッドで発生した例外やコンソールで発生した例外等は、<br>
	全てこのUnhandledExceptionイベントをハンドルして処理すればよい。		全てこのUnhandledExceptionイベントをハンドルして処理すればよい。<br><br>

	上記2つのイベントを活用して未処理の例外を実際に処理しているのが、次のサンプルコードである。		上記2つのイベントを活用して未処理の例外を実際に処理しているのが、次のサンプルコードである。<br><br>

	== サンプルコード ==		== サンプルコード ==