Tasuku SUENAGA
a****@razil*****
2008年 6月 2日 (月) 13:55:15 JST
すえながです。 >> sen_enc2strみたいな関数があるのですが、 >> それと同じノリですよね。 >> 僕もあると便利だと思います。 > はい、そんな感じです。 ほいー。でも、エラーハンドリングの方法が変わるとなると、 必要性がちょっと減るかもですね。 > ついでなので、エラーの通知方法についてです。 > もう少し具体的なエラーの内容を通知するのはどうでしょうか？ > (中略) > もし、これを実現するためには以下のどちらかかと思います。 > * sen_rcをもう少し細かくする > * enumじゃなくてエラーオブジェクトを作る 新API系については、すべてsen_space配下になる…と思います。 というわけで、ひとつ案を提案させていただきます。 返り値はエラーがあったかどうかが判別できるだけにして、 エラーの具体的内容が知りたければ sen_space_get_last_error(長い…)みたいな関数を呼んでね、 というエラー取得方法もありかもしれません。 sen_rcを返すのは、通常大多数の関数呼び出しが成功するので 軽量でよいと思うのですが、 やはり詳細なエラー情報（エラーメッセージ、エラーの起こった関数等） を知りたいケースも多いですよね。 Ruby bindingなどでは、返り値をチェックして、 エラーだったらget_last_errorしてraiseをする、 みたいな書き方でイケると思います。 問題は、last_errorの上書きですね。 sen_spaceって1スレッド1個で スレッド間共有は出来ない感じでしたっけ？ sen_rcを増やすのは結構キツいと思います。 どこまで詳細化するかどうかの明確な基準がないですし、 詳細化したところで結局得られる情報が少ないからです。 新APIの素案でも、sen_other_errorというのを使っちゃっていますね… --- すえなが
