タグ

Programmingとエラー処理に関するatsushifxのブックマーク (2)

  • TypeScript エラー処理パターン - Object.create(null)

    M 年前にも N 年後にも人類は同じ話をしている. まとめ エラーの発生方法は throw と return に大別できる throw には簡潔さ, return には明瞭さと型安全性といった特徴がある どちらの方法がより適しているかはプログラムの規模, エラーの種類, ハンドリングの方法などが判断の材料になる 実際にどちらの方法を使うかは上の判断材料と, フレームワークやプロジェクトのコーディング規約なども合わせて複合的に決めるのがよい エラー発生方法の分類 まず前提として, 関数から呼び出し元にエラーを伝える方法は以下の 2 つに大別できます. 逆にこの記事ではこれ以上の具体的な方法についての議論はしません. throw エラーを throw して呼び出し元に伝える方法です. 例えば以下のようなものが当てはまります. throw new Error("...") Promise.rej

    TypeScript エラー処理パターン - Object.create(null)
  • Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱

    二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ! 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる. それはそうと例外設計において"無視"は大罪である. だから、関数を呼び出したら戻り値は漏らさずチェックすべきだ. ということで、例えば以下のように逐一戻り値をチェックする. if(send(sockfd, buf, len, 0) < 0){ ERROR("send"); exit(1); } あぁ、面倒だ. 一体コードのどの部分が正常系の処理なのか? ほとんどエラーハンドリング*1で埋め尽くされるじゃないか. そもそもエラーハンドリング部分に書くのは毎回同じコードだし、コードの繰り返しは防ぎたい. エラー処理部分をラッピングして楽をする unpv12eの中でラッパーを被せることによってこの面倒を回避する方法を知った. in

    Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱
    atsushifx
    atsushifx 2014/11/01
    一応Cにもsetjmp/longjmpマクロはあるが、使えるものではないしな。そもそもコーディングの大部分は引数のチェック、やりたい処理の準備と後始末、エラー処理がしめる。正解自体まだなさそう
  • 1