SODA Noriyuki @n_soda @master_q ARM と Effective C++ と Exceptional C++ を読んで、人間だけからなるプロジェクトチームを作るのは無理だと分かりましたw(ぉぃ 2011-11-22 15:07:40
例外の分類
元ネタは、C#チームのEric Lippert氏のブログの数年前の投稿です。 例外処理というと、「とりあえずキャッチしとけ」とか、逆に「とりあえずキャッチするな（集約例外ハンドラーで対処しろ）」とか言われたりします。かと思えば、「プロなんだから自分の頭で考えろ」とか、「業務フロー次第でしょ」などと千尋の谷に突き落とされたりもします。 極論を言えばそうなのですが、もう少しガイドラインとなるものは無いのか、ということでEricのブログの内容をかいつまんで紹介します。 Ericは、例外は4種類に分類できると言っています[1]。 例外の4分類（Eric Lippert氏による） 種類説明特徴対処方法例 致命的な例外（fatal exception） プロセスに深刻な問題が発生し、今にも死にそうな状態にある場合に発生する例外。 プログラマーの過失ではない[2]、 復旧は無理（finallyを実行する
はてなダイアリー埋め込みテストも兼ねて。 LLVMでの例外の扱いは基本的にgccと同じようです。libgccを使って投げた例外を受けることができます。 gccの例外をゼロから実装するにはぱーそなりてぃふぁんくしょんというとても面倒な関数を書かないといけませんので、手を抜いてlibstdc++(g++のランタイム)とlibgnat(GNATのランタイム)を使って例外を投げてみました。 ↑とほぼ等価なC++コード #include <cstdio> int main() { try { throw 0; } catch(int) { std::puts("int"); } catch(float) { std::puts("float"); } return 0; } ↑とほぼ等価なAdaコード with GNAT.IO; procedure main is begin raise
assert()は、第一引数にboolean、第二引数にオプションでエラーメッセージを取る。呼び出しが成功した場合は、関数の戻り値を返す。例えば、以下のio.open()はエラーの場合、第一引数にnil、第二引数にエラーメッセージを返す。なので、以下の呼び出し方は定石となる。 file = assert(io.open(name, 'r')) 逆に、自作の関数で、エラー処理をする場合、以下の2パターンがある。 本。また、第二引数の型は文字列ではなく任意でよく、エラーコードを返しても良い。 package.loadlib()でのWin32
目次 ホーム 連絡をする Blog 利用状況 投稿数 - 1078 記事 - 2 コメント - 26135 トラックバック - 363 ニュース 著作とお薦めの品々は 著作とお薦めの品々は 東方熱帯林へ。 わんくま 東京勉強会#2 C++/CLI カクテル・レシピ 東京勉強会#3 template vs. generics 大阪勉強会#6 C++むかしばなし 東京勉強会#7 C++むかしばなし 東京勉強会#8 STL/CLRによるGeneric Programming TechEd 2007 @YOKOHAMA C++・C++/CLI・C# 適材適所 東京勉強会#14 Making of BOF 東京勉強会#15 状態遷移 名古屋勉強会#2 WinUnit - お気楽お手軽UnitTest CodeZine Cで実現する「ぷちオブジェクト指向」 CUnitによるテスト駆
前に取り上げた「Plan 9 ソースコードでの例外機構 使い方編」の続きです.こんどは実装について. Plan 9のプロセスでは例外をサポートするために, それを表すProc構造体に特殊なメンバを導入しています.以下に挙げるnpc/dat.h ty
Plan 9のソースコードを読んでいると以下のような関数が頻繁に出てきます. ailed!"); 10 11 } 12 13 pop
普通のC++使い、銀天すばる @SubaruG std::next_permulation を使う場合は do-while が便利です。 RT @aizen76: do-whileに関しては仕事を通しても一度も使った事がないな… 2011-01-08 15:23:02 普通のC++使い、銀天すばる @SubaruG swap( a.first, a.second ); RT @tozangezan: pairは二つの値を入れ替えるのにmake_pair(a.second,a.first)でいけるので楽ということに気がついた 2011-01-08 15:45:28 普通のC++使い、銀天すばる @SubaruG @tozangezan std::swap は C++ やるなら覚えておいたほうがいいです。使うときは std::swap( a, b ); じゃなくて using std::swa
void methodA () { ... if (str != null) { methodB (str); } } void methodB (String str) { ... } （呼び側主義） とするか。 呼ばれ側主義者の主張はこう。 呼び元で null check すると複数箇所に同じ check コードが分散し、コード量を増大させる null check をせずに NullPointerException が発生するのは恥ずかしい 事実これまで、呼ばれ側で null check しないと困ることが多かった（プラグマティズム） 一方、呼び側主義者の主張はこう。 メソッド先頭に null check の if 文がずらずらと並ぶのは可読性を損ねる JDK のライブラリ群だって null を入れたら NullPointerException を投げている この議論は平行線をたどり、
エラーと例外 Posted by ぴろり Posted at 2010/11/20 13:51 Trackbacks 関連記事 (0) Post Comment コメントできます Category コーディング スタイルの話題の一つに、関数はエラーを返すべきか、例外を返すべきか、というテーマがあります。普段は Perl、C++ も疎遠なので、例外自体ほとんど使っていないんですが。帰りの電車の中でちょこっと考えてみたので、そのメモ。 | | | | 情報の流れる方向、境界線 こんな感じか？ 情報の流れる方向、境界線 関数呼び出しを行った際に、その関数内部で何か問題が発生したときに、それはエラー値を返すのか、例外を投げるのか、といった議論です。これでは少し曖昧なので、考えるポイントを明確にします。私が注目したのは、情報の流れる方向と、関数との入出力を行う境界線、という
For over 20 years, Xlib has been at the heart of most graphical applications and user interface frameworks on Unices, including GNU/Linux. It is also knows as libX11, the actual name of the shared library in the file system. Unfortunately - and given its age, perhaps unsurprisingly - it suffers from some rather troublesome limitations and designs mistakes. This brought a few smart developers to cr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
