［C++］ 例外送出からキャッチまでのあいだ - 地面を見下ろす少年の足蹴にされる私
C++のthrow式はどんな型のオブジェクトであっても投げることができます。この是非は置いておいて、あるthrow式に対して適切にcatch節（例外ハンドラ）が用意されている場合に、呼び出される例外ハンドラは厳密にどのように決まるのでしょうか？なんとなくthrow式の引数と同じような型ならマッチする気はしますが、そのルールは関数のオーバーロード解決時のものとは異なる気がします。 catch節での型マッチング 例外ハンドラで使えない型 例外オブジェクトの型 例外オブジェクトの状態 例外ハンドラ引数の初期化 コピー省略が起こるところ 例外オブジェクトの寿命 std::exception_ptr 例 余談 : 決して選択されない例外ハンドラ 参考文献 catch節での型マッチング 例外オブジェクトの型をEとすると、対応する例外ハンドラの決定はそのcatch節の宣言型（以下、ハンドラの型）とEをマ
例外、エラー、異常、そして - 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
Swift 2.0 の try, catch ファーストインプレッション - Qiita
WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。本投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている（検査例外のような形） try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ
便利かもしれないGCC builtin - にゃははー
これは恐らくC++ Advent Calendar 2014の15日目です。 古来[要出典]より人々はいかに例外を投げた奴をトレースするかに命をかけてきた[要出典]。 投げられた例外自体や、そのメッセージを確認することはできるが、一体誰がその例外を投げたかという情報は一切乗らないからだ。 いっそのことsegfaultでもしてくれたほうがデバッガでスタックトレースを出力できる。 ある人は考えるだろう。 template <typename Base> struct exception_info : Base { explicit exception_info(const Base &base, const char *file, int line) : Base(base), file(file), line(line) {} virtual ~exception_info() noexce
Cのエラーハンドリングと例外設計、例外処理のメモ - 百日半狂乱
二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ！ 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる． それはそうと例外設計において"無視"は大罪である． だから、関数を呼び出したら戻り値は漏らさずチェックすべきだ． ということで、例えば以下のように逐一戻り値をチェックする． if(send(sockfd, buf, len, 0) < 0){ ERROR("send"); exit(1); } あぁ、面倒だ． 一体コードのどの部分が正常系の処理なのか？ ほとんどエラーハンドリング*1で埋め尽くされるじゃないか． そもそもエラーハンドリング部分に書くのは毎回同じコードだし、コードの繰り返しは防ぎたい． エラー処理部分をラッピングして楽をする unpv12eの中でラッパーを被せることによってこの面倒を回避する方法を知った． in
textdrop.net - このウェブサイトは販売用です！ - textdrop リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
例外設計における大罪 - 契約
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
処理開始後の例外処理では「サニタイズ」が有効な場合もある
このエントリでは、脆弱性対処における例外処理について、奥一穂氏(@kazuho)との会話から私が学んだことを共有いたします。セキュアプログラミングの心得として、異常が起これば直ちにプログラムを終了することが推奨される場合がありますが、必ずしもそうではないというのが結論です。 はじめに Webアプリケーションの脆弱性対策では、脆弱性が発生するのはデータを使うところであるので、データを使う際の適切なエスケープ処理などで対処するのがよいと言われます。しかし、処理内容によってはエスケープができない場合もあり、その場合の対処についてはまだ定説がないと考えます。 エスケープができない場合の例としては、以下があります。 SQLの数値リテラルを構成する際に、入力に数値以外の文字が入っていた メール送信しようとしたが、メールアドレスに改行文字が入っていた 入力されたURLにリダイレクトしようとしたところ、U
エラー処理を書いてはいけない
エラー処理を書いてはいけない田中英行 tanaka.hideyuki@gmail.com 2011/12/08 @PFIセミナー 自己紹介田中英行 (@tanakh, http://tanakh.jp) PFI社でプログラマやってますJubatuspficommon検索エンジンのコアエンジンHaskell愛好家msgpack / rpc / idlpeggy (パーザジェネレータ & QQ w/ AQ)Shu-thing (シューティングゲーム) / (Monadius メンテナ)今気になるパッケージは monad-controlLearn you a Haskell 鋭意翻訳中 （春頃発売予定） エラー処理を書いてはいけない本日の概要エラー処理を抽象化しようというお話です 現在のエラー処理の抱える問題どのように解決するのか実際の例エラーは処理しなければならない エラー処理を書いてはいけな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外を投げるな、値を返せ