これは 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 で発表した際にも参考文献にしまし
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
世間ではオワコンと揶揄されることも珍しくない Java ですが、Java を初めたばかりのエンジニアがチェック例外と非チェック例外の使い分けについて「ベストプラクティスないの？」と調べたのをまとめてみました。 エントリまとめ どのエントリも Java についての深い洞察と開発の実践現場での生きた経験をもとに書かれていて大変に勉強になりました *1 エントリ中からリンクされているエントリもぜひ一読されることをおすすめします。 検査例外と非検査例外(実行時例外)をどう使い分けるか - Lino Blog Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指して Javaのチェック例外はクソ仕様 - やさしいデスマーチ 例外の扱いについて その２ - じゅんいち☆かとうの技術日誌 「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
辻ロックフリーしたつもりが話題が発展して、間違いを許容するモデルの定義と実装そのものが面倒なんじゃないかという話になりました。 そういえばWindowsって「ユーザー環境は手に追えない事になってる」という前提によって、理由をこじつけてはすぐに再起動要求してきますよね。ある意味で「間違いを許容するソフトウェア」かも知れないです。
2017-04-16 FreeBSD/mpd 2016-12-23 RecentDeleted Blogアプリ 日記 2016-11-17 本当にあった怖いコード/1 2016-05-16 .NET 2015-07-06 書きたいこと 2015-07-05 postgres Java/変数の初期化に安易に空オブジェクトを代入しない 2015-06-30 PukiWiki/1.4/マニュアル/プラグイン/u 本当にあった怖いコード/15 2014-10-01 日記/2014-10-01 2014-09-09 日記/2014-09-09 2014-08-13 日記/2014-08-10 2014-05-28 バグパターン/日時 バグパターン 2014-04-13 IPv6 2014-03-20 パスワード問題 2014-01-27 DNS/ルートサーバーは13台という神話 2014-01-25
ソフトウェアの開発において、エラー処理は、時には本来の機能よりも重要です。業務として開発するソフトウェアでは、本来の処理を行うためのコードよりも、エラー処理のコードの方が量が多くなることも良くあります。 ところが、実際のソフトウェアの開発では、エラーをどこでどのように出力するかについては、実装者任せになってしまうことが多いようです。ソフトウェア設計書を見ても、エラーの出力については記述されていないことも良くあります。実装が終わってから、最後に慌しくエラーの出力を組み込むこともあります。 エラー処理について考えてみると、たくさんの難しい問題があることが分かります。これらの問題を理解した上で、きちんとエラー処理の仕組みを考えないと、ソフトウェアの設計や品質にも、重大な影響が及ぶかもしれません。 エラー処理とログ出力は、本来、どのようにして行うべきなのでしょうか。 エラーを知らせる仕組み ソフト
言うまでもなく、COBOLなベテランは非同期バッチ処理の達人が多い。 日本ではこの手のベテランが多い。 まず世界でも例がないほどだと思う。 クラウド時代はむしろ非同期処理のオンパレードであり、 学ぶべき点はたくさんある。 こと運用レベルや、対障害設計は神レベルの人が多いので まじでノウハウは受け継ぐべし。 個人的に達人系の技のポイントをまとめておく 1.コンテキストを外部から与える 一種のDI的な考え方である。 但し、あくまで運用目線であることが重要。 通常のDIは開発効率を目的に考えていることが多く見受けられるが 非同期処理についてのDI的な考えは運用効率性の重視だ。 対障害設計をする上で、もっとも大事なことは 「コンテキストがまっさきに見えることだ。」 これはDI的は発想とはまるで違う。 今走っている処理は、 ・どういうモノで、 ・何を想定していて、 ・どういうスケジュールになっていて
JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース) の 13 日目の記事です． Node といえば非同期プログラミングですが，そのスタイルは大雑把にわけて 2 種類あります．一つ目は fs モジュールなどで使われているコールバック関数のスタイル． fs.readFile(path, function(err, content) { if (err) { // エラー時の処理 return; } // 成功時の処理 });このスタイルは，何らかの要求に対する結果を一発で受け取る (要求と結果が 1 対 1) 場合に使われます．そして，コールバック関数の第1引数でエラーの有無が通知されます．エラーがなければ null，エラーがあった場合は Error オブジェクトというのが原則のような気がしますが，undefined が渡されたりする
エラー処理を書いてはいけない田中英行 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 鋭意翻訳中 （春頃発売予定） エラー処理を書いてはいけない本日の概要エラー処理を抽象化しようというお話です 現在のエラー処理の抱える問題どのように解決するのか実際の例エラーは処理しなければならない エラー処理を書いてはいけな
gccの__attribute__((cleanup(fn))) が便利すぎる件について。 C++でコードを書くときは、RAIIとか呼ばれているイディオムを使えば、ご存じの通り、ロックしたmutexを手動で開放する必要もないですし、newしたオブジェクトを手動でdeleteする必要もないです。 void Baz::boo() const { boost::mutex::scoped_lock lock(mutex); // ... return; // lock変数のデストラクタで自動開放。手動での開放不要 }でもC言語だと、当然ながら手動で開放しないといけません。複数箇所でreturnしている場合など、タイプが面倒臭すぎ。 int foo() { pthread_mutex_lock(&mutex); // ... if (hogehoge) { pthread_mutex_unlock
元ネタは、C#チームのEric Lippert氏のブログの数年前の投稿です。 例外処理というと、「とりあえずキャッチしとけ」とか、逆に「とりあえずキャッチするな（集約例外ハンドラーで対処しろ）」とか言われたりします。かと思えば、「プロなんだから自分の頭で考えろ」とか、「業務フロー次第でしょ」などと千尋の谷に突き落とされたりもします。 極論を言えばそうなのですが、もう少しガイドラインとなるものは無いのか、ということでEricのブログの内容をかいつまんで紹介します。 Ericは、例外は4種類に分類できると言っています[1]。 例外の4分類（Eric Lippert氏による） 種類説明特徴対処方法例 致命的な例外（fatal exception） プロセスに深刻な問題が発生し、今にも死にそうな状態にある場合に発生する例外。 プログラマーの過失ではない[2]、 復旧は無理（finallyを実行する
gistのはてなダイアリー埋め込みテストも兼ねて。 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パターンがある。 error()関数を呼び出し、エラーを発生させる 失敗の場合は、第一引数にnil(もしくはfalse)、第二引数にエラーメッセージを返す つまり、Luaではエラーを上側に伝播したい場合、エラーコードを返すのではなく、nilとエラーメッセージを返すのが基本。また、第二引数の型は文字列ではなく任意でよく、エラーコードを返しても良い。 package.loadlib()でのWin32API
目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1078 記事 - 2 コメント - 27231 トラックバック - 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構造体に特殊なメンバを導入しています.以下に挙げるnerrlabとerrlabがそれにあたります. これらはそれぞれ, 登録されたラベルの個数, 配列です. /sys/src/9/port/portdat.h : 長いので抜粋 struct Proc { ... int nerrlab; Label errlab[NERR]; ... }ここでいうラベルとはエラー時に戻るべき, waserror()関数が呼び出された場所を表します.具体的には以下のようなLabel構造体を用いてこれを保持しています.それぞれスタックポインタとリターンアドレスを格納するためのメンバがあります. /sys/src/9/pc/dat.h ty
Plan 9のソースコードを読んでいると以下のような関数が頻繁に出てきます. error() waserror() poperror() nexterror() これらはC言語で例外をサポートするためにPlan 9で利用される関数です. 具体的には以下のように使います 1 int func(){ 2 if( waserror() ){ 3 recover_from_error(); 4 return ERROR; 5 } 6 7 // below could err 8 if( !do_something_has_error() ){ 9 error("failed!"); 10 11 } 12 13 poperror(); 14 return SUCCESS; 15 } recover_from_error()とdo_something_has_error()はコードを書く人が挿入した任
銀天すばる（SubaruG） @SubaruG std::next_permulation を使う場合は do-while が便利です。 RT @aizen76: do-whileに関しては仕事を通しても一度も使った事がないな… 2011-01-08 15:23:02 銀天すばる（SubaruG） @SubaruG swap( a.first, a.second ); RT @tozangezan: pairは二つの値を入れ替えるのにmake_pair(a.second,a.first)でいけるので楽ということに気がついた 2011-01-08 15:45:28 銀天すばる（SubaruG） @SubaruG @tozangezan std::swap は C++ やるなら覚えておいたほうがいいです。使うときは std::swap( a, b ); じゃなくて using std::swa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く