REIGAI REIGAIせよ!
昨日のカオスの続き。
- 例外は「エラーを取り扱う手段の一つ」として考案されたもので、それ以外を扱うのはマナー違反。よって例外を投げることはエラーであることを上位レイヤーに報告するものであるが、エラー自体は必ずしも例外ではない(ほかにも手段はある)
- どういったものがエラーなのかについては、関数にとって何が正常なのかを定義して、その否定がエラーである、と考えればなんとかなるんじゃないか?
そのためには多分関数が何であるかが決まってる必要があるんじゃないか。例えば「ファイルをオープンする」とか。
で、正常ってのが関数が何であるかに従って動作している間のことで、正常なまま終了するとそれは正常に終了したってことでいいか。
例外が飛んできて捕捉して続行した場合はなんだろう?捕捉して続行したということは、その関数にとっては想定内の出来事だったのでエラーではない?
想定内だとエラーじゃないのか?どうなんだ? - 下から飛んでくる例外が必ずしも自分にとってもエラーとなるわけではない…
- 何であるかが決まっていれば、それを達成できなくなった状態がエラーであり、エラーはエラーなりの対処をしなければいけない。手段としては、例外、関数のインターフェース(戻り値、引数)、とか。
- 達成できなくなった状態ってのは、現在のコンテキストでは、というのが付いている。それより上位のレイヤーだけが知ってる情報とかは関係ない。そんなものは知らん、俺にはでけへんかった。だからエラーなんだ。
- ただ、エラーとは何かは定義できたけど、それはあくまでも「エラーだよ」っていうことだけで、「こういうエラーだよ」ってのはまだ。
- 「こういう」って部分はこれ一体なんなんでしょうね?内容?内容ならその内容はどうやって表現するの?型?例外でやるなら型しかないか。
- そういえばC++の例外は全てソフトウェア的な例外だっけ?ハードウェア的な例外は知らんぷり。まぁC++は一介のプログラミング言語でしかないので、ハードウェア例外まで知らんよってことで。でもこのあたりは区別する必要性はない気がする。重要なのはそれをどのレイヤーが扱うか(扱えるか?)だと思う
- 投げる側も発生するエラーの原因は多々あると思うし、そうなるとこれ情報をどういう塊として投げればいいんだ…
- ていうか型で例外を捕捉するの無理じゃね?CSSセレクタ以上に柔軟な仕組みがいるとか
- コンパイラのコンパイルエラーを例外とみたてて、普通のプログラムの例外と対比してみてどんな感じなんだろうとか思索にふける
- 一個エラーがでた時点であと全ては実行しなくてもいいけど、とりあえずそこは適当になんかやっといてできる限り残りもコンパイルする…
- もともと例外状態なんだからパフォーマンスを求める必要はないにしても、できる限りやってしまうというのはちと無駄すぎると思う
- うーん、結局のところ例外はインターフェースの一部で、しかもエラーのインターフェースの一部で、丁寧なコンパイルエラーを出力するのが大変なように、うまいエラー情報を出力するのも大変だなぁっておもいました まる
- 例外投げる側は今分かってること投げればいいけど、投げられる側にとってはそんな自由奔放に投げられると捕捉するのが大変だからもうちょっと考えろよお前らみたいな