エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
2010-04-17
とても欲しい。 pcall と error で似たようなことはできるけど、やはり不十分だし。 明らかな異常系以外... とても欲しい。 pcall と error で似たようなことはできるけど、やはり不十分だし。 明らかな異常系以外で例外に頼らなければいけない状況は変だ、と思い直した。 気軽にぽんぽん例外を投げるような設計は、どうなのだろう、と。 その辺は言語の文化も関わってくるけれど、例えばC++だと、例外は基本的に「例外的な事情」がある時しか投げないような設計が多い( boost::lexical_cast のような例外も多いが)。 そういう「よくできたC++のライブラリ」は、事前チェックで例外を投げることを殆ど回避できる仕組みになってるし、例外を気軽に投げる設計のライブラリでも、例外が投げられることが正常な実行パスの中に含まれるようなプログラムを書くような事は、基本的に行わない。 もっとも、この辺は正に言語の文化次第である。 例えば Python では、 for 文という基本的な構造において、処理終了