- PR -

Socket.Exceptionでハンドルされていない例外

«前のページへ 1|2|3|4
投稿者投稿内容
少管閑事
会議室デビュー日: 2003/10/17
投稿数: 8
投稿日時: 2004-01-13 23:22
Jubeiさん、Jittaさん、レスありがとうございます。

ご指摘の変更を試みて、サーバが存在しない場合については問題解決しました。たいへん失礼いたしました。
Connectをtryブロックの中に入れたら、サーバが存在しない場合にcatchに来ることを確認しました。
マイクロソフトのチュートリアルでConnectがtryブロックの外にあったため、Connectに例外ハンドラは定義されていないものと勘違いしておりました。

こちらについてはお粗末な結論で、大変失礼いたしました。

ただサーバが存在してポート番号が禁止されている場合、tryブロックの中にConnectを入れると、今度はConnectで以下のメッセージが現れて緑色中断します。

「'System.Net.Sockets.SocketException' のハンドルされていない例外が system.dll で発生しました。追加情報 : 対象のコンピュータによって拒否されたため、接続できませんでした。」

・チュートリアルのとおりにtryの外にConnectを出すと、GetStreamで緑色中断します。
・tryの内にConnectを入れると、Connectで緑色中断します。

サーバが存在してポートが禁止されている場合、catchに来てくれません。
Jubei
ぬし
会議室デビュー日: 2002/03/02
投稿数: 830
お住まい・勤務地: 関西
投稿日時: 2004-01-13 23:50
諸農です。

引用:

少管閑事さんの書き込み (2004-01-13 23:22) より:

ただサーバが存在してポート番号が禁止されている場合、tryブロックの中にConnectを入れると、今度はConnectで以下のメッセージが現れて緑色中断します。

「'System.Net.Sockets.SocketException' のハンドルされていない例外が system.dll で発生しました。追加情報 : 対象のコンピュータによって拒否されたため、接続できませんでした。」

・チュートリアルのとおりにtryの外にConnectを出すと、GetStreamで緑色中断します。
・tryの内にConnectを入れると、Connectで緑色中断します。

サーバが存在してポートが禁止されている場合、catchに来てくれません。



すみません。投稿されている意図がわかりません(^^;
同じ例外クラスが発生しているのに、同じようにトラップできないのは何故なんですか？

2004-01-12 17:20で投稿した私のサンプルコードですが、
サーバーは存在していて、ポート禁止または接続禁止の状態で行いましたが、
問題なくトラップできています。
もちろん例外のメッセージは「2004-01-13 13:31」に投稿しているとおり、
「対象のコンピュータによって拒否されたため、接続できませんでした」の
内容がListBoxに表示されて、再試行を３回行い、その後に再試行ルーチンを
抜けます。アプリケーションの異常終了と言ったことは回避できています。

その、少管閑事さんがトラップ出来ないと言われているコードを、
BBタグなどを利用してインデントした形式で、不具合と言われている現象を
再現できる最小限のコードをアップしていただけませんか？

そうして頂かないと、議論が全然前に進みません。

＃この内容って、私的にはまったくネットワーク云々とは違う話だと
＃思っています。
＃どちらかと言えば単純な基礎プログラミングの話ではないでしょうか。

どうかよろしく検討してくださいませ。

--編集追加--

まさかとは思いますが「タスクの例」で紹介されているコードの

コード:

    // Verify that the server exists

    if (Dns.GetHostByName(server) == null) {

      Console.WriteLine("サーバー {0} が見つかりません", server);

      return;

    }

    // Try to connect to the server

    tcpc.Connect(server, 13);  //←ここで緑色中断？


の部分のことですか？

先の投稿で、Connect()はtryブロックに入れたということでしたので、
コード:

    if (Dns.GetHostByName(server) == null) {

      Console.WriteLine("サーバー {0} が見つかりません", server);

      return;

    }

    try

    {

       tcpc.Connect(server, 13);  //←ここで緑色中断？

    }

    catch(Exception /*E*/)

    {

    }


のようになっているんでしょうか？

--再度追加
つまり、GetHostByName()で例外が出ているってことですか？
--追加終わり

もしも、そうであり、それで例外が捕捉出来ないといわれているのでしたら、
少し失礼な表現になるかもしれませんが、
何のためにtryで括るのかとか、例外保護ブロックの意味についてや、
プログラミングの基本部分について書籍などを購入して勉強されることをお勧めします。

_________________
諸農和岳
Powered by Borland Delphi/C++Builder & Microsoft VS.NET

[ メッセージ編集済み 編集者: Jubei 編集日時 2004-01-14 00:06 ]

[ メッセージ編集済み 編集者: Jubei 編集日時 2004-01-14 07:32 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-01-14 11:01
　MSの技術情報を、「VS.NET」カテゴリから「KBBUG」をキーに検索すると、こんなのがありますね。

「[BUG] Visual C# .NET で、ステップ実行の際にデバッガが制御ブロックを正しく指さない」
http://support.microsoft.com/default.aspx?scid=kb;ja;316447&Product=vsnetINT


　例外がどこで発生して止まったのか、ステップ実行で追いかける方が良いみたいですね。
Jubei
ぬし
会議室デビュー日: 2002/03/02
投稿数: 830
お住まい・勤務地: 関西
投稿日時: 2004-01-14 12:21
諸農です。

引用:

Jittaさんの書き込み (2004-01-14 11:01) より:

「[BUG] Visual C# .NET で、ステップ実行の際にデバッガが制御ブロックを正しく指さない」


フォローアップありがとうございます。

引用:

　例外がどこで発生して止まったのか、ステップ実行で追いかける方が良いみたいですね。


この情報は、デバッグにおける注意点としてすこぶる有益だと思います。
ただ、今回、少管閑事さんが新たに2004-01-13 23:22で投稿された件に関しての、
根本的な解決への道筋とは外れていると思います。


ご提示いただいた情報では
「MSIL/ネィティブコードへの影響は無い」
とのことですので、実際の実行時には影響は無いものと認識しています。

もともと、少管閑事さんから提示されている問題（2004-01-12 09:39）の
内容というものは、
「SocketException例外」をアプリケーションコードでトラップできなくて、
アプリケーションが異常終了してしまう、ということだったと認識しています。

そして、先の投稿にもあったように、単なるコーディングミス（プログラ
ミングミス）を頑なに間違っていないと勘違いされていたことから、
私を含め、第三者にいろんな疑惑や妙な推測を発生させていたことに尽きた
議論展開になったのだと思います。

そして、再び提示された「トラップできない例外」ですが、
これも、これまでと同様、発生しているのは同じ例外クラスです。

もしも、本当に、.NET Framework上でプログラム製造者の想定している構造化
例外処理が出来ない状況にあるのでしたら、これは大問題だと思います。
多くの人からマイクロソフトに、または技術系掲示板やメーリングリストに、
数多くの問題指摘の投稿がされることになると予想されます。

さて、新たに提示された問題の「同じ例外クラスをトラップできない現象」について
ですが、ここで私に想像できることは、プログラム製造者が、前回同様、間違った例
外保護のコーディングをしているのではないか？ということです。
その疑問を払拭するには、再現性のある最小限のコードを提示していただくのが、
最善の方法なのではないか、と私自身は思うわけです。

何故、少管閑事さんが、障害発生を再現できるコードを提示してくれないのかが
すこぶる疑問なんですが、提示していただければ多くの人に目を通していただく
ことが期待でき、しかも目を通していただいた方から、再現性の確認を含めて
いくつかのリプライがあれば、

１．System.Net.Sockets名前空間のクラスが持つ未発見のバグなのか
２．FCLがプログラマが想定する構造化例外を正しく処理できないというバグなのか
３．単にプログラムコード（プログラミング）が間違っているだけなのか

の切り分けも可能だと思うのです。

プログラムコード上で例外発生が予測される細部の個所を、プログラマが判定でき
ないのであっても、例外保護の仕組みを理解することでアプリケーションの
異常終了は回避できるはずです。
先の投稿でも述べたように、例外保護を行いたい処理を一つのルーチンにまとめて、
そのメソッドを呼び出すコードを例外保護すれば良いと私自身は思っています。

こういった検証可能なテストコードを書かずに、また、第三者に提示することなく、
「バグだ、なんだ」とだけ騒ぎ立てる姿勢は、個々人の持つプログラミングスキルに
発展性が無くなる、と個人的には感じています。
少なくとも、少管閑事さんが「FCLのネットワーククラスのバグではないか云々」と
発言し、コードの提示も無いのであれば、最低限の検証を自前で行って、
その内容をわかりやすく説明していただけたら、と思います。

_________________
諸農和岳
Powered by Turbo Delphi & Microsoft Visual Studio 2005

十兵衛＠わんくま同盟
http://blogs.wankuma.com/jubei/
«前のページへ 1|2|3|4

スキルアップ／キャリアアップ（JOB@IT）