タグ

エラーに関するshoronpooのブックマーク (5)

  • 例外、エラー、異常、そして - Qiita

    「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected

    例外、エラー、異常、そして - Qiita
  • Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱

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

    Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱
  • Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita

    これは Swift Tweets の発表をまとめたものです(次回開催はこちら)。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました!Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし

    Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
  • エラー処理の地学史、もしくはあなたがMaybeモナドを使うべき理由。 | 月と燃素と、ひと匙の砂糖

    (以下、カノッサの屈辱(テレビ番組)のノリでお願いします) コンピュータの理論を確立したチューリング。彼は、無限のテープの長さを持ち、単なる計算を行うだけのチューリングマシンを夢想した。 しかし、我々の生きる現実世界におけるコンピュータでのプログラムに於いては、計算の失敗=エラーが発生するのは避ける事ができない宿命である。ネットワーク接続失敗、ファイルが見つからない、メモリが確保出来なかった…等々。すべてのエラーを書き出すには、それこそ無限の長さの紙が必要であろう。プログラム進化の歴史は例外との戦いであると言っても過言ではない。今回の講義では、プログラミング言語の様々な進化のうちの「エラー処理」に着目し、その長い戦いの歴史を概観する。 まずは、いにしえの先エクセプション紀におけるエラー処理を見てみよう。 先エクセプション紀:エラーコード-1の時代 エクセプション(exception)と呼ば

  • エラーチェックの体系的な分類方法 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs

    まず最初のエントリでは、「エラーチェック」とひとくくりにされている「エラー」を、体系的に分類することを試みてみます。このエントリでは、Web / Windows、あるいは Java / .NET などといった技術論とは無関係な部分についての解説を進めていきたいと思います。 エラーチェック(ユーザ入力検証)の意味 正常終了/業務エラー/システムエラーの分類 業務エラーの細分化 アーキテクチャから見たエラーチェックの実装場所 ※ なお、エントリで解説されている分類方法や命名方法は、あくまで nakama 個人の考え方・整理方法です。もしかしたらもっとよい設計パターンなどがあるかもしれませんので、その辺についてはあしからずご了承ください;。 [エラーチェック(ユーザ入力検証)の意味] まずは、そもそもどのようなケースでエラーチェックが必要になるのか、ユーザ入力検証にどのような目的があるのかを考

    エラーチェックの体系的な分類方法 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
  • 1