Delphiの例外処理を理解する - Qiita
JavaやらPHPとかの例外処理をやっていたら、Delphiの例外処理って特殊というか、誤って理解している部分があったと認識しましたので、改めてまとめてみました。 Javaの例外処理 Javaの例外処理はスッキリしている（と思います）。 try { 例外が起きるかもしれない処理 } catch(AException e) { 例外AExceptionが発生した場合の処理 } catch(BException e) { 例外BExceptionが発生した場合の処理 } catch(CException | DException e) { 例外CExceptionかDExceptionが発生した場合の処理 } finally { 例外が起きても起きなくても行う処理 } tryブロックを抜けたら行う処理 catch節は、捕捉する例外に応じて続けることができます。finally節は、処理が不要なら
Ruby関西 勉強会で「プロを目指す人のための例外処理（再）入門」という発表をしてきました #rubykansai - give IT a try
はじめに 2017年1月13日（土）に開催された第80回 Ruby関西勉強会で「プロを目指す人のための例外処理（再）入門」という発表をしてきました。 会場はすごくきれいで快適な、大阪梅田のグランフロントにあるAimingさんでした。 （どうもありがとうございました！） このエントリでは僕の発表内容と、勉強会中のエピソードを書いていきます。 発表スライド 当日使用した僕の発表スライドはこちらです。 例外処理については過去にいろいろ痛い目に遭わされているのと、間違った使い方をしている初心者さんをよく見かけるので、「お願いだから正しく使って！！」という気持ちでこのスライドを作りました😅 例外処理にまつわる僕の体験談については「本当にあった怖い話」としてスライド内で紹介していますw その他にも例外処理のバッドプラクティスやベストプラクティスなど、例外処理を書くときは絶対に押さえておきたいポイント
むかしむかし、あるところにチェック例外という機能があったそうな | システムアーキテクトのごった煮
ってことで、例外のお話です。 どうも僕の知っている限りでは、チェック例外という言語機能をもっているのはJavaだけみたいです。 僕個人としては、すばらしい機能なんですが。 Javaで最初にチェック例外を学んだ時、「そうそう、これこれ、これが欲しかったのよ！」 って思ったあの頃の想いは今も色あせていません。 「ずっと好きだったんだぜ～♪」って斉藤和義の曲を口ずさむくらいに、今もチェック例外を愛しています。 しかし、このチェック例外、他の言語からdisられまくって、最近の言語には取り込まれないという悲しいお話になっています。 過去に様々な議論があった中で、結論としてチェック例外は役に立たないってことになったらしいです。 経緯は知らんがね、そんなん。僕には役立ってるんだから。 ってことで、僕の立場から見た、チェック例外についての考察と扱いを書きます。 反論したい方、自重をお願いします。 だって、
Pythonメモ : better-exceptionsで例外情報を見やすくする - もた日記
better-exceptions インストール 使い方 better-exceptions github.com better-exceptionsを使用すると例外情報が図のようにみやすくなる。 インストール pipでインストールできるので下記コマンドを実行。 $ pip install better_exceptions 使い方 以下のようにbetter_exceptionsをインポートすればよい。 import better_exceptions 試しに下記コードを実行した場合の出力を比べてみる。 import better_exceptions foo = 52 def shallow(a, b): deep(a + b) def deep(val): global foo assert val > 10 and foo == 60 bar = foo - 50 shallow(b
LLVMで例外を実装するには - yhara.jp
LLVMを使った自作言語に例外を入れることを考えてた。結論からいうとCrystalのソースを真似するのでよさそう。 Crystal → libunwind → _Unwind_RaiseException C++ → __cxa_throw → libunwind → _Unwind_RaiseException _Unwind_RaiseException等の仕様はここ。http://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html 「Itanium C++ ABI」という名前ではあるけれど、Level I, II, IIIのうちのLevel I部分(_Unwind_RaiseException等)はC++に限らない言語独立なAPIになっている。__cxa_throwはLevel IIで、C++用のもの(であるけれど、場合によってはこれが使えるこ
try { return } finally {} | POSTD
class Test { public int aaa() { int x = 1; try { return ++x; } catch (Exception e) { } finally { ++x; } return x; } public static void main(String[] args) { Test t = new Test(); int y = t.aaa(); System.out.println(y); } } 上の質問に回答する前に、次の問題には答えられるでしょうか？ try ブロック内に return 文がある場合、 finally ブロックは return の実行時に処理されるのでしょうか。 finally が実行されるなら、いかにして return と finally の両方の実行が実現するのでしょうか。 もし答えが分からなければ、どうぞこのまま読み進め
例外、エラー、異常、そして - 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
Javaの検査例外は、呼び出し側で「どんなに注意しても防げない」異常系 - Qiita
注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査
Node.js における Promise を使った例外処理 - from scratch
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
Haskellの最近の例外ハンドリング - syocy’s diary
どうもHaskellには標準のControl.Exceptionモジュールだけでなくmtlやexceptionsやexceptionalといった例外を扱うためのパッケージがあるらしいのだが、そのあたりのパッケージの選び方や使い方についてまとまった情報を見つけられなかった。 HaskellWiki例外のページも少々古いようで、deprecatedなものや統合される前のパッケージを書いていたりする。 調べた限り、mtlとexceptionsが今の主流っぽい。 その2つの使い方をまとめる。 なおバージョンはlts-6.1を基準としている。 mtl mtlパッケージのControl.Monad.ExceptモジュールはMonadErrorというモナドとExceptTというモナド変換子を提供する。 以下のように使う。 import Control.Monad.Trans(lift) import C
実践!! RuboCopプラグイン開発入門 - SideCI TechBlog
こんにちは。RuboCop大好きpockeです! SideCIでは対応ツールの追加など、主にサーバーサイドの開発を担当しています。 今回は、SideCIでも使用しているRubyの静的解析ツール、RuboCop のプラグインの作り方について書こうと思います。 実際にRuboCopプラグインを作りながら手順を解説します! はじめに 今回は、よくあるバグを検出するCopを作ってみましょう。 以下のコードにはバグがありますが、一見しただけだとその存在に気が付かないかも知れません。 def foo raise StandardError "error!" end 本来このコードには、StandardErrorと"error!"の間にカンマが必要です。 カンマが抜けていると「StandardErrorというメソッドを"error!"という引数で呼び出す」という意味になってしまい、想定しない挙動になって
Java で引数の null チェックで迷った話 - yukungのブログ
これは Java Advent Calendar 2015 の 15 日目の記事です。 昨日は @opengl_8080 さんの Byteman 使い方メモ＋α でした。明日は @irof さんです。 前置き ついこないだチームでちょっとだけ話題に上って、みんなある程度指針は持っているものの、割と悩みつつ明確に答えを出せなかったので、もっと良い意見があればと思って晒してみます。まぁよくある話だし、Java 8 で Optional が使えるようになって null について語られるケースが増えたと思うので、再考するちょうどよい機会になればいいなーと思います。初心者向けです。 どう処す？処す？ こんな状況の時にあなたならどうしますか？ // Generics なのは例です。String でもなんでもいいです public T doSomething(T input) { // input が
Javaの例外処理について - 水まんじゅう2
これはJavaアドベントカレンダーの5日目です。 最近例外処理について考えなければいけないことがあったので、こうしたほうが良いよというのをまとめます。 他の言語からJavaに移ってきた場合に微妙なところで変な感じになることがあるので。 ここで扱うJavaの例外というのはThrowableとそのサブクラスのことです。 Javaにはtry〜catch〜finallyという例外を扱うための構文があります。 try { } catch(Throwable t) { } finally { } Java7からはtry-with-resourcesや例外のマルチキャッチという新しい構文も増えました。 そちらについて詳しく知りたい人は[twitter:@skrb]さんの現場で使える[最新]Java SE 7/8 速攻入門をご参照お願いします。 現場で使える［最新］Java SE 7/8 速攻入門 作者:
JUnit4での例外テストを楽チンにする！ - Qiita
2018/6/13追記 jUtaime は JUnit5 の登場によりその使命を終えました。 長らくご愛顧ありがとうございました m(_ _)m みなさま JUnit5 を使いましょう。 What's an issue ? JUnitでの例外検証コードをもっとスッキリ書きたいっ！ そう思っているのはきっと私だけではないはず・・・ before 例えば Person#setAge(int) なんていうよくあるメソッドを作ったとして、次の4点を検証したい。 setAge(-1) は NG → IllegalArgumentException をスロー setAge(0) は OK setAge(200) は OK ： 超長寿社会の到来に備えて。 setAge(201) は NG → IllegalArgumentException をスロー、例外メッセージあり 通常のJUnit4ではこんな感じ
契約による設計から見た例外 - Qiita
正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、
例外のカレンダー | 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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
Exception and Error-Log (Server Side)
news
POTD: ExceptionInInitializerError logger