dRubyコミュのシリアライズできない例外

サーバ側でシリアライズできない例外が発生した場合、
A なんとしてもシリアライズする
B 参照渡して、クライアントがさまざまな情報を再問い合わせする
Cシリアライズ可能な例外に変換する
が考えられます。

Aは作り込んで行くのがつらい。
BはdRubyらしくて好みなんだけど、例外が発生している状況で
いろいろ問い合わせするのはなんとなく微妙だし、原因の例外が
GCされないで保持されているかなあ、とかどきどきする。
で、Cにしようかなあと思ってます。
CにしてもAを組み合わせるのは可能ですし…

コメント(2)

最初
全て
最新の40件

[1] mixiユーザー 12月11日 16:26

ruby-list を見た感じだと、既に C の方法で完成してる感じなんでしょうか？
DRbRemoteError はどの例外のサブクラスになるんでしょうか？

素人考えでは B なのかなぁと思ったものの、よくよく考えてみると確かに GC が厳しそうな気もします。
なかなか難しいものですね…。

[2] mixiユーザー 12月11日 16:39

例外のサブクラスです。これだけ…。
本来の例外を与えてnewします。
実際にはDRbMessageのdumpの中でこっそり生成されます。

class DRbRemoteError < DRbError
def initialize(error)
@reason = error.class.to_s
super("#{error.message} (#{error.class})")
set_backtrace(error.backtrace)
end
attr_reader :reason
end

ログインすると、みんなのコメントがもっと見れるよ