[#38080] ポートが閉じているときの例外など — Mitsuru Ogino <ogino@...>

荻野と申します。いつも質問や要望ばかりですみません。

36 messages 2003/08/11
[#38086] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/12

なかだです。

[#38088] Re: ポートが閉じているときの例外など — IWAOKA Masahiro <iwaoka@...> 2003/08/12

いわおかです。

[#38091] Re: ポートが閉じているときの例外など — Mitsuru Ogino <ogino@...> 2003/08/12

荻野です。

[#38092] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/12

なかだです。

[#38093] Re: ポートが閉じているときの例外など — IWAOKA Masahiro <iwaoka@...> 2003/08/12

いわおかです。

[#38095] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/12

In message <20030812150516.GV37221@barber.fe.rn.tuat.ac.jp>

[#38102] Re: ポートが閉じているときの例外など — Tetsuo NAKAGAWA <tet@...> 2003/08/14

中川と申します。

[#38121] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/15

In message <20030814.140757.707824131.tetsuo@sapphire.siz.nes.nec.co.jp>

[#38123] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/16

なかだです。

[#38130] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/16

In message <200308160517.h7G5HcPL012839@sharui.nakada.kanuma.tochigi.jp>

[#38137] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/18

なかだです。

[#38139] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/18

In message <200308180959.h7I9xnb7001977@sharui.nakada.kanuma.tochigi.jp>

[#38122] ruby-tcpwrap and mkmf.rb — Takahiro Kambe <taca@...>

こんにちは。

16 messages 2003/08/16
[#38125] Re: ruby-tcpwrap and mkmf.rb — "Akinori MUSHA" <knu@...> 2003/08/16

At Sat, 16 Aug 2003 12:51:55 +0900,

[#38183] String << の動作につきまして — kuto@...

うと と申します。

44 messages 2003/08/22
[#38187] Re: String << の動作につきまして — Take_tk <ggb03124@...> 2003/08/22

たけ(tk)です。

[#38189] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38190] Re: String << の動作につきまして — Take_tk <ggb03124@...> 2003/08/23

たけ(tk)です。

[#38191] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38194] Re: String << の動作につきまして — Take_tk <ggb03124@...> 2003/08/23

たけ(tk)です。

[#38196] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38203] Re: String << の動作につきまして — 西 啓一朗 <receiver@...> 2003/08/23

ども、西啓一朗@Ktouth Brand. です。

[#38208] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38211] Re: String << の動作につきまして — 西 啓一朗 <receiver@...> 2003/08/24

ども、西啓一朗@Ktouth Brand. です。

[#38195] 理解の進め方(Re: String << の動作につきまして) — Tadashi Oh-Ya <toy@...>

おおやです。

36 messages 2003/08/23
[#38206] 理解の進め方:シュールな世界 — Take_tk <ggb03124@...> 2003/08/23

たけ(tk)です。

[#38233] シュールな名前 — Take_tk <ggb03124@...> 2003/08/25

たけ(tk)です

[#38198] Tmailで送るメールに日付がつけられなくなりました — 川田誠司 <kawada.seiji@...>

はじめまして

11 messages 2003/08/23

[#38256] かみ砕いた説明をすべき範囲 — 西 啓一朗 <receiver@...>

ども。西啓一朗@Ktouth Brand. です。

41 messages 2003/08/26
[#38258] Re: かみ砕いた説明をすべき範囲 — nobu.nakada@... 2003/08/26

なかだです。

[#38261] Re: かみ砕いた説明をすべき範囲 — Take_tk <ggb03124@...> 2003/08/26

たけ(tk)です

[#38262] Re: かみ砕いた説明をすべき範囲 — nobu.nakada@... 2003/08/26

なかだです。

[#38264] Re: かみ砕いた説明をすべき範囲 — Take_tk <ggb03124@...> 2003/08/26

たけ(tk)です

[#38265] Re: かみ砕いた説明をすべき範囲 — IWAOKA Masahiro <iwaoka@...> 2003/08/26

いわおかです。

[#38267] Re: かみ砕いた説明をすべき範囲 — Take_tk <ggb03124@...> 2003/08/26

たけ(tk)です

[#38273] Re: かみ砕いた説明をすべき範囲 — matz@... (Yukihiro Matsumoto) 2003/08/26

まつもと ゆきひろです

[ruby-list:38131] Re: ポートが閉じているときの例外など

From: Minero Aoki <aamine@...>
Date: 2003-08-16 12:59:53 UTC
List: ruby-list #38131
青木です。

  In mail "[ruby-list:38113] Re: ポートが閉じているときの例外など"
    Mitsuru Ogino <ogino@verama.net> wrote:

> 荻野です。お騒がせしています。

> > ちなみに、Proto*Error はまとめて obsolete にするつもりです。

> 今から obsolete になるのであれば、ProtoTimeoutOnConnectError(長い…)
> などの名前を増やすべきではない、ということでしょうか。

はい。


> なぜ非推奨になるのか、教えていただけないでしょうか。Proto という名前が
> 適切かどうかはともかく、TCP 層のエラーを、アプリケーション層にまとめる
> という意味であれば、ちょっとそれは違和感を覚えます。IO や Socket レベル
> のエラーに統一するというのであれば、賛成できると思います。

いまは SMTP と POP と HTTP のエラーが全部 ProtocolError から
派生してるんですが、これをあるべき姿に直そうっていうだけです。

  StandardError
      ProtocolError
          ProtoXXXError

          ↓

  StandardError
      SMTPError
          SMTPXXXXError
      POPError
          POPXXXXError
      HTTPError
          HTTPXXXXError

というふうに。コネクション関係のエラーは元々 Proto*Error には
入れてないので関係ありません。


> > あと、#finish で IOError を
> > 投げたりしますけど、これも SMTPError なりの下位クラスに変更
> > すべきだと思いますか?
> 
> かなり汎用的な(呼び出し側でも使いそうな)TimeoutError と違って IO を使って
> いて、IOError を返すというのは、それはそれなりに筋が通っていると思います。
> 
> というか #finish が IOError(かそのサブクラス)を返すのであれば、接続失敗
> (相手が応答しなくて TimeoutError になった場合を含む)でも IOError などの
> 下位層のエラーだとわかる方が、SMTP のエラー(5xx)や POP3 のエラー(-ERR)
> とかと区別できてすっきりする、というのが私の感覚です。

それは同意します。しかし多重継承が存在しない以上 TimeoutError と
IOError を同時に継承することができません。そうすると、open 時の
タイムアウトはどちらかにしなければならないのですよね。


> # しかし、IOError で送信を確認すべしというのは、リファレンスマニュアルにな
> # かったので、気がつきませんでした。

確か、CVS HEAD の英語マニュアルには書いたんですよ。
日本語マニュアルは更新が面倒で……。


> Proto*Error というのが、SMTPError とかと同類項(アプリケーション層のエラー)
> というのであれば、「接続時のエラーは ProtocolError のサブクラスの方が」と
> いうのは撤回します。趣旨は、アプリケーション層のエラーと下の層のエラーは
> 分かれていた方がいいということです。

この点も同意します。


> 逆に、TCP や socket のレベルで接続に失敗した場合の例外が SMTP とか POP3 とか
> で個別に定義されていると、それはそれでリファレンスをみる回数が増えてちょっと
> 躊躇します。が、リファレンスマニュアルに書いてあればそれはそれで受け入れられ
> ることかと。

従って、こういうことをするつもりはありません。


> で、SMTP とかで接続が成功したとき後の読み出しの timeout だけが、ちょっと異質
> な感じですね。SessionTimeoutError とかにしても、実質は IOError のサブクラスで
> あるべきように感じます。(しかし互換性の問題があるので変えるべきではないでと
> は思います)

そうですねえ。これはちょっと解決策を思い付きません。
当面は、コネクション関係は IOError TimeoutError Errno::E*、
それより上のエラーは Net::HTTPError を拾え、ということにしましょう。

いちおう TimeoutError のサブクラスも作りますかね。
-------------------------------------------------------------------
青木峰郎

In This Thread