try-catchからrunCatchingに_移行した話.pdf - Speaker Deck
Transcript try-catchからrunCatchingに 移行した話 安齋祐紀 (@off2white) 自己紹介 安齋祐紀（あんざいゆうき） Twitter: @off2white 株式会社 ディー・エヌ・エー（DeNA） - 次世代タクシー配車サービス「 MOV」 - Androidアプリ開発担当 - プロジェクト管理とコーディングの割合 = 50:50 (気持ちは) 最近の悩み いまだに運営さんが採択時に 人を間違えていなかったのか心配 None 背景 個人的エラーハンドリング の変遷 その１ むやみに例外を使わなくなった ClassA ClassB ClassC Exception New ClassD 誰が Catch する？ NewException Not For Me Exception ？ ClassA ClassB ClassC sealed class N
「例外」がないからGo言語はイケてないとかって言ってるヤツが本当にイケてない件 - Qiita
この記事は、Go3 Advent Calendar 2018 の８日目の記事です。 ７日目は @codehex さんによる「Go でアプリケーションとクライアントのミドルウェアを作成する方法知ってますか？」でした。 本日はネタ全開でお送りいたします。 Disclaimer（免責事項） はじめに言い訳というか、これを書いた経緯というか。 プログラミング言語をdisる人をdisる芸を見たいですね！ — yet another (@Maki_Daisuke) 2018年10月11日 というツイートをいたしまして、言った手前自分でやるか、と思い立った次第です。 なので、ネタとしてお楽しみください。 なお、炎上した場合にも、それすらもネタとして楽しむ所存ですのでアシカラズ。 それでは、いってみましょう。 Go言語がイケてない…だ…と……？ Go言語はイケてない言語としてよくdisられているが、その中
Go ではエラーを文字列比較する？という話について : DSAS開発者の部屋
Go で関数の戻り値のエラーを判別するときに、エラーメッセージの文字列をチェックするコードが存在します。 (例) これは、 Go が言語設計としてエラー処理が貧弱だったり、標準ライブラリがエラー処理を軽視しているからでしょうか？ 言語設計や標準ライブラリのAPIの設計をみて行きましょう。 TL;DR 言語設計としては、Java的例外機構と同等以上の（文字列比較によらない）エラー検査が可能 ただし Go のエラーに関する哲学により、公開されていないエラーが多い 実際にエラーを文字列比較されている実例についての解説 Go のエラー検査方法 Java の例外機構では、例外をキャッチするために専用の構文が用意されており、型によりマッチングすることができます。 これはクラスのツリー構造を利用してサブクラスをまとめて分岐することもできます。 一方で、同じクラスでも値によりエラー処理が異なる場合には、
例外のカレンダー | Advent Calendar 2014 - Qiita
例外やエラー、それにまつわる各種言語の取り組み等を共有しましょう。 11月末までに書き手が集まらなかった場合は主催者による独りAdvent Calendarと化します。 集まらなかったので残念ながら独りAdvent Calendarと化しました。 追記 独りAdvent Calendarですが、以下の理由で頓挫しました。6日目以降はお好きにご活用ください。 http://qiita.com/Kokudori/items/3a953c00012408f76ab9#%E4%BE%8B%E5%A4%96-advent-calendar-2014%E3%81%AE%E7%B6%99%E7%B6%9A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
例外安全と例外中立 - Qiita
現代のC++で例外安全問題を抜きにして、障害に強い強固なコードを書くことはほとんど不可能に近い。以上。 Hurb Sutter [1] 例外処理における目的は、例外の回復と例外の通知の大きく2つあります。残念ながら例外の回復はとても難しく、場合によってはそもそも不可能だったりします。その場合、例外が発生したことをより上位のレイヤーに通知する事で例外処理を託します。この時、例外の通知を受け取った側は何を前提に例外の回復を行えばよいでしょうか。例外の発生によってデータ整合性は崩れてしまっているかもしれません。通知を受け取った上位レイヤーはあらゆる状態を想定して例外の回復を試みなければならないのでしょうか。もしそうだとすれば、ただでさえ難しい例外の回復がいよいよもって現実的ではなくなってしまいます。 明らかに上位レイヤーが持つべき前提条件が存在します。これは例外を通知する側が満たすべき保証と言い
Error Handling
Share: Error Handling in Node.js Error handling is a pain, and it’s easy to get by for a long time in Node.js without dealing with errors correctly. However, building robust Node.js applications requires dealing with errors properly, and it’s not hard to learn how. If you’re really impatient, skip down to the “Summary” section for a tl;dr. This document will answer several questions that programme
エラーを無視しがちなPHPで安心ガードする、または「require strict;」 - uzullaがブログ
イケプロ*1が禁忌する言語PHP！！（挨拶） イケピチ*2のuzullaです。今年は休み長いですね！！最高！！（仕事しながら） その理由の一つとして、カジュアルにエラーを無視して進み続ける所ですよね。 例 <?php echo $a; // 未定義変数 echo "I wanna die"; たとえばこのような未定義変数の参照。 これはE_NOTICEレベルのエラーが出ますが（出ない設定もあるが）、あくまでnoticeなので無視して先に進みます。 一般的なプログラマからは「ハァ？変数無いとかどう考えてもFATALだろ…笑顔でNOTICEって何事。これだから宣言無しのPHPは…」って言われますね。 実際自分もそう思う、なんでこれでとまらないのかな、とめられないのかな、俺がアホなのかな*3。 つーか、そもそもNOTICEはちょっと前のデフォルトだと出ないですね*4。 NO MORE NOTIC
扱いづらいPHPのエラー処理を適当にいなす - uzullaがブログ
追記 この記事のやり方でもいいっちゃいいのですが、PHP7以降では"set_error_handler"でエラーを例外に変換せず、"Error"例外を直接キャッチするほうがよりスマートだと思います。 PHP: PHP 7 でのエラー - Manual なので「例外でキャッチできないエラーがある」というのがほぼなくなった感じですね。 （ただし、"Error"は"Exception"と兄弟関係なので、全部キャッチするつもりのcatch(\Exception $e)ではキャッチできない事に注意。） 追記終わり。 PHPはエラーが扱いづらい いきなりですけど、PHPはエラーが扱いづらい言語だと思います。(おっと、最初の行からPHP Disだ、ブクマが稼げる) 「サーバーにPHPをアップロードして、ブラウザで試行錯誤する」というスタイルを実現するために、なにかあってもInternal Server
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計における大罪 - 契約