[#38020] irb で %W(#{...}) — yoshihisa masuda <sacong@...>
マスダといいます。
[#38036] undef variable — hirocy <hirocy@...>
hirocyです.
[#38039] proc method — "K.Sasada" <ko1@...>
こんにちは。ささだです。
[#38056] ファイル書換え? — 中村文建 <tx6f-nkmr@...>
初めまして、MLに参加させて頂く中村と申します。
[#38057] [ANN] Ruby-GNOME2-0.6.0 — Masao Mutoh <mutoh@...>
むとうです。
[#38059] [ANN] rbbr-0.3.0 — Masao Mutoh <mutoh@...>
むとうです。
[#38073] module extendable? — Takeshi Horinouchi <horinout@...>
堀之内と申します。
[#38080] ポートが閉じているときの例外など — Mitsuru Ogino <ogino@...>
荻野と申します。いつも質問や要望ばかりですみません。
なかだです。
いわおかです。
荻野です。
なかだです。
いわおかです。
In message <20030812150516.GV37221@barber.fe.rn.tuat.ac.jp>
中川と申します。
In message <20030814.140757.707824131.tetsuo@sapphire.siz.nes.nec.co.jp>
なかだです。
In message <200308160517.h7G5HcPL012839@sharui.nakada.kanuma.tochigi.jp>
なかだです。
In message <200308180959.h7I9xnb7001977@sharui.nakada.kanuma.tochigi.jp>
なかだです。
まつもと ゆきひろです
[#38090] ruby-1.8 で eruby が SEGV — Kazuhiko <kazuhiko@...>
かずひこです。
[#38104] XMLRPC::ModRubyServer — OHARA Shigeki <os@...>
大原です。
[#38122] ruby-tcpwrap and mkmf.rb — Takahiro Kambe <taca@...>
こんにちは。
At Sat, 16 Aug 2003 12:51:55 +0900,
In message <200308160518.h7G5IXPL012842@sharui.nakada.kanuma.tochigi.jp>
なかだです。
In message <200308160714.h7G7ErPL014647@sharui.nakada.kanuma.tochigi.jp>
前田です。
In message <87d6f3znlc.wl@kirk.priv.netlab.jp>
前田です。
わたなべです。
[#38164] Ruby1.8.0でRuby-PostgreSQLがビルドできない — kensaku Maki <sakaki@...>
はじめまして、まきと申します。
[#38183] String << の動作につきまして — kuto@...
うと と申します。
たけ(tk)です。
ふなばです。
たけ(tk)です。
ふなばです。
たけ(tk)です。
ふなばです。
ども、西啓一朗@Ktouth Brand. です。
ふなばです。
ども、西啓一朗@Ktouth Brand. です。
[#38195] 理解の進め方(Re: String << の動作につきまして) — Tadashi Oh-Ya <toy@...>
おおやです。
たけ(tk)です。
In "[ruby-list:38206] 理解の進め方:シュールな世界"
たけ(tk)です
[#38198] Tmailで送るメールに日付がつけられなくなりました — 川田誠司 <kawada.seiji@...>
はじめまして
[#38256] かみ砕いた説明をすべき範囲 — 西 啓一朗 <receiver@...>
ども。西啓一朗@Ktouth Brand. です。
なかだです。
たけ(tk)です
なかだです。
たけ(tk)です
いわおかです。
たけ(tk)です
まつもと ゆきひろです
たけ(tk)です。
たけ(tk)です。
[ruby-list:38131] Re: ポートが閉じているときの例外など
青木です。
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 のサブクラスも作りますかね。
-------------------------------------------------------------------
青木峰郎