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

On 2003.8.14, at 13:52 Asia/Tokyo, Minero Aoki wrote:

> ちなみに、Proto*Error はまとめて obsolete にするつもりです。
> もちろん残しますが、積極的には推奨しません。net/protocol.rb 自体、
> そのうち消す予定です。

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

# on の後ろに名刺だと Connection? エラー名は思いつきなので、
# 英語の確かな人の意見が欲しいです。

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

# Protocol ってどの層でもあるので直感的でない、ということは思います


>> # 個人的には接続時のエラーは ProtocolError のサブクラスの方が使いやす
>> # いようにも思うのですが、よくわかりません。
>
> うーん、個人的にはエラーはごっそりまとめて処理しちゃうんで
> うまく分類する自信がありません。

すみません、どっちかというと好みの問題かと思うので、ポリシーさえはっきり
していて、かつ仕様が明確で安定であれば、それでいいと思います。


> あと、#finish で IOError を
> 投げたりしますけど、これも SMTPError なりの下位クラスに変更
> すべきだと思いますか？

かなり汎用的な（呼び出し側でも使いそうな）TimeoutError と違って IO を使って
いて、IOError を返すというのは、それはそれなりに筋が通っていると思います。

というか #finish が IOError（かそのサブクラス）を返すのであれば、接続失敗
（相手が応答しなくて TimeoutError になった場合を含む）でも IOError などの
下位層のエラーだとわかる方が、SMTP のエラー（5xx）や POP3 のエラー（-ERR）
とかと区別できてすっきりする、というのが私の感覚です。

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

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

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

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

-- 
荻野 充 (おぎの みつる) ... 「萩(はぎ)」にあらず
Verama Systems

Key fingerprint = 7F26 5414 1805 F31B 1617  10B7 C117 07AE 1691 9BD1