Swiftのエラーハンドリングはなぜ最先端なのか - Qiita
Swiftのエラーハンドリングは他のメジャーなプログラミング言語のどれとも異なる新しい仕様を持っています。特に、検査例外を持っているのですが、これはJavaで採用された以降はほとんどの言語で採用されていないため、現代では否定されている過去の間違いだったと広く認識されていると思います。そのため、Swiftユーザーで無い人は、検査例外という言葉をみた瞬間に興味を失ってしまうため、その詳細がなかなか世の中に伝わっていないと感じています。一方、私はこんなSwiftのエラーハンドリングをとても気に入っていて、様々な言語の進化の歴史を踏まえた産まれた最も優れた最先端の仕様だと思っています。この記事ではその考えを説明します。 Javaのエラーハンドリング Javaは検査例外を持っています。これにより、あるメソッドがエラーを送出するかどうかを関数のシグネチャとして静的に表明できます。 // 検査例外の例
PHP でどのように Exception/RuntimeException/LogicException を使い分けるか - Qiita
PHP は各種プログラム言語の中でも比較的高級な (表現力が豊かで最適な記述を選ぶのに知識を必要とする) 例外モデルを持っていると言えます。そんな PHP の例外の各区分とその使い分けを整理し、PHP の例外モデルの設計意図を考察したいと思います。 PHP例外の分類 PHP の例外は Java とは異なり、(Error を合わせると) 合計 4 つの区分に分類されます。Java には 2 区分しかありません。(PHP では Java の Error に相当するものは発生しません。PHP の Error は Java では RuntimeException の一種に分類されています) PHP Java
和田卓人さん、PHPで堅牢なコードを書く—例外処理、表明プログラミング、契約による設計 〜PHPカンファレンス2016 | gihyo.jp
PHPカンファレンス2016 レポート 和田卓人さん、PHPで堅牢なコードを書く—例外処理、表明プログラミング、契約による設計 〜PHPカンファレンス2016 2016年11月3日にPHPカンファレンス2016が開催されました。本稿では、ゲストスピーカーである和田卓人さんによる講演「PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計」についてレポートします。 PHP7では例外や表明の機能が大幅に見直され、強化されました。この講演では、例外処理を設計する際の基本的な考え方や、表明（assertion）の使い方、そして表明と例外を使い分け、堅牢なコードに導くための設計手法「契約による設計（Design by Contract）」の考え方を説明しました。 導入 はじめに、和田さん自身が監訳に関わった『SQLアンチパターン』に掲載されているコードを、よりひどくさせた
JavaScriptエンジニアなら知ってるよね？ エラー処理のいい書き方、悪い書き方
JavaScriptのエラー処理、ちゃんと書いていますか？ エラーを無視せず、どこに問題があるのか、きちんと確認できるコードの書き方をデモで紹介。 この記事はTim SeverienとMoritz Krögerが査読を担当しています。最良の記事を提供することができ、SitePointの査読担当者の皆さんに感謝します。 JavaScriptのエラー処理には危険が潜んでことを知っていますか？ もしマーフィーの法則を信頼しているとしたら、不具合が生じる可能性が本当に高いです！ この記事では、JavaScriptのエラー処理について考え、その落とし穴から便利な実践例までを説明します。さらに最後には、非同期コードとAjaxにも触れます。 JavaScriptはイベント駆動型プログラムで、プログラミングをより豊かなものにしてくれます。ブラウザーをイベント駆動型プログラムと考えると、発生するエラーは同一
Java 歴 23 分の Ruby エンジニアが Effective Java を読んで感動した話 - scramble cadenza
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
Java/Androidにおける例外設計、あるいは「契約による設計」によるシンプルさの追求 - Qiita
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 （契約プログラミングについて） Effective Java読書会9日目 - 例外 （Javaにおける例外の扱いについて） 契約による設計から見た例外 （この記事の方がより詳しいけど難しいイメージ） チェック例外と非チェック例外の違い チェック例外→「回復
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
脱ビギナー！Androidのnullな話 - クックパッド開発者ブログ
新規広告開発部の松本です。 クックパッドiOS/Androidアプリの広告の開発に携わっています。 Androidアプリ開発の際、皆さんはnullをどのように扱っていますか？また、nullチェックを行うのであれば、どのような基準で行っていますか？私自身まだまだAndroid開発歴が浅いため、特に何か基準がある訳でもなく至る所でif (foo != null)といったnullチェックを行おうとしていました。 これに対し、先日の社内コードレビューでとてもためになるアドバイスをもらいました。私のようなAndroid初心者にとってnullに対する考え方の基礎を作ってくれるレビューだったので、本稿で共有したいと思います。 また、AndroidやJava開発に慣れた方にとっては「今更そんな話か」といった内容かと思いますが、クックパッドでのレビューの一例としてご覧いただければ幸いです。 やりがちなnul
例外処理の書き方について - Qiita
public class hogeAction { public String main() { try { ・・・ ビジネスロジック ・・・ } catch (Throwable e) { return null; } return foo; } } このようになんでもCatchしちゃう包容力の高いコードをたまに見る。 こういうコードを見つけると、「臭うぞ！！」と思うのは自分だけだろうか？ まあ直接的すぎるのもあれなので、 「ちょっと例外処理広すぎやしませんか？ 例外処理は必要最低限の範囲で意図したものだけCatchしましょうよ」 くらいにレビューフィードバックしたりする。 言語やチームに限らず、ここまで激しくなくても、必要以上に大きくTry Catchで囲って必要以上にCatchする書き方をするエンジニアを数多く見てきた。 なぜこういうコードが生まれるのか あまりにも多いので、こういう
JNIとC++例外 - meryngii.neta
JNI関連の話が続きます。 今日は短いですが、JNIとC++例外について。 最近ではAndroid NDKもC++の例外（やRTTI）に対応していて、そのおかげで例外が必要なSTLなどのライブラリを自由に使えるようになっています。しかし、Java側はC++の例外を理解してくれないので、もしJNIを介した関数がネイティブ領域で例外をキャッチし損ねると、すぐにSegmentation Faultで落ちます。 解決策としては、JNIから呼び出されたC++側の内部処理を、noexceptな関数に閉じ込めてしまえばよいわけです。もちろんエラーが発見できないのもまずいので、JNIを使ってJava側の例外に変換してしまいます。 JNIEXPORT void JNICALL Java_Foo_bar (JNIEnv* env, jobject thisj) { jni_util::convertExcep
JavaScriptと非同期のエラー処理
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo!デベロッパーネットワークの中野(@Hiraku)です。前回のコールバック地獄に関する記事では、複雑な入れ子になりやすい非同期処理でも、GeneratorやjQuery.Deferredを使うことで、同期的な見た目に変形できることを示しました。 ところで、非同期処理においてはもう一つ「 エラー処理に例外が使えない 」という問題があります。今回はエラー処理について考えてみたいと思います。 例外を使ったエラー処理 非同期処理の話の前に、一度「例外」についておさらいしておきましょう。JavaScriptに限らず、エラーと言えばよく例外を使って記述されます。 「Web APIから500が返ってきた」とか「入力された値が期待する型
Androidアプリ開発で例外の発生した場所を特定する | DevelopersIO
以前、「iOSアプリ開発で例外の発生した場所を特定する」というブログを書きましたが、 Androidでも同じような機能があるようです。(むしろ、Javaですが。。。) Thread クラスの setDefaultUncaughtExceptionHandler メソッドというものを使いますが、 ここでオリジナルのクラスをセットすることにより、キャッチしてない例外発生によってアプリが強制終了したときの 「問題が発生したため、xxx(アプリ名)を終了します。」という、みなさんおなじみ？ のダイアログが表示される前に、任意の処理を差し込むことができます。 今回はそれを利用して、例外発生時のスタックトレースを SharedPreferences に保存して、メール送信するサンプルを作ってみます。 開発時などは、アプリをデバッグ起動していればEclipseのLogCatで例外発生時のスタックトレース
iOSアプリ開発で例外の発生した場所を特定する その２ | DevelopersIO
前回は、例外の発生した場所を特定する方法として、「NSSetUncaughtExceptionHandler」を使った方法を紹介しました。 今回は、Xcodeの機能の「Exception Breakpoint」を使用して、例外の発生した場所を特定してみます。 （前回のブログで頂いたコメントを参考にしました。ありがとうございました。） 環境は、Xcode 4.5 を使用します。 例外を発生させる処理は前回と同じなので省略します。 以下、手順です。 ① Breakpointアイコンのボタンをクリックして、「Breakpoint Navigator」を開きます。（ショートカットは、「⌘」+「6」） ② 「+」ボタンをクリックします。 ③ 「Add Exception Breakpoint...」をクリックします。 ④ 「Done」ボタンをクリックします。 設定はこれで終わりです。 では、実行して
iOSアプリ開発で例外の発生した場所を特定する | DevelopersIO
iOSアプリを開発していて、例外が発生してアプリがクラッシュしてしまうことがしばしばあります。 Xcodeでは、クラッシュ時に得られる情報が少ないので、原因究明に時間がかかってしまいます。 そんなときは、「NSSetUncaughtExceptionHandler」を使用すると便利です。 まず、試しに、よくある例外をわざと発生させてみます。 - (void)viewDidLoad { [super viewDidLoad]; // ここで、わざと例外を発生させてみます。 [[NSArray array] objectAtIndex:0]; } 実行すると以下のようになります。 「UIApplicationMain」で止まってしまって、状況がよくわかりません。 「NSRangeException」が発生したことくらいはわかりますが、もう少し情報が欲しいところです。 そこで、「NSSetUnc
Java のチェック例外と非チェック例外の考察まとめ - 全力で怠けたい
世間ではオワコンと揶揄されることも珍しくない Java ですが、Java を初めたばかりのエンジニアがチェック例外と非チェック例外の使い分けについて「ベストプラクティスないの？」と調べたのをまとめてみました。 エントリまとめ どのエントリも Java についての深い洞察と開発の実践現場での生きた経験をもとに書かれていて大変に勉強になりました *1 エントリ中からリンクされているエントリもぜひ一読されることをおすすめします。 検査例外と非検査例外(実行時例外)をどう使い分けるか - Lino Blog Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指して Javaのチェック例外はクソ仕様 - やさしいデスマーチ 例外の扱いについて その２ - じゅんいち☆かとうの技術日誌 「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
安全なJavaScriptを書く
例外設計における大罪 - 契約
