バグ論 - TrickDiary
細かい論説すっとばしてますが、いつまでもネタを寝かしたままにしておくのもよくないので、以下、要点だけでも・・・ エントロピー(複雑さ)には勝てない 数学的視点による見解 複雑な方程式はいとも簡単に解のない式となる。 仕様のレベルで、複雑な要求に対しバグがない仕様は論理的に存在できなくなる。 プログラムも同様に、複雑な仕様に対しバグがないプログラムは論理的に存在できなくなる。 生物学的視点による見解 生物(生体)は複雑さに対して「大小様々な問題があろうが致命的な問題がないように」というアプローチでこの問題を克服している。 これらを踏まえたバグとのつきあい方 どんなに科学が進歩しようが「絶対に間違った判断をしないAI」などというものは論理的に無理。 可能な限り簡略化を試みる。 生物(生体)と同じアプローチを採用する。 バグがあってもそれを隠蔽する方向で実装する。 デバッグ版では逆に asser
例外原理主義 - TrickDiary
「れいがい！」、「REIGAI REIGAIせよ！」、「そろそろれいがいさんへの思いを適当にまとめる」も参照のこと。 assert/エラー/例外の区別。 意味論上、本質的な違いはない。現状の実装などの都合で使い分けるもの。 問題の通知に使用される場合の signal やモナド*1等も意味論上、本質的な違いはない。 本来これらは同じような構文で記述できるべき。 assert/エラー/例外の使い分け。 なにか問題が起きた場合は基本的に例外を投げる。 リリース版ではそもそも発生することがあってはならない類の問題については assert を使用する。 パフォーマンスが問題にならない場合は assert とともに例外やエラーを併用することを推奨。 問題が起きても無視してよいものあるいは例外ではパフォーマンスや呼び出し側の実装の都合が悪い場合にはエラーする。 assert/エラー/例外の役割。 問題が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
