Swiftのエラーハンドリングはなぜ最先端なのか - Qiita
Swiftのエラーハンドリングは他のメジャーなプログラミング言語のどれとも異なる新しい仕様を持っています。特に、検査例外を持っているのですが、これはJavaで採用された以降はほとんどの言語で採用されていないため、現代では否定されている過去の間違いだったと広く認識されていると思います。そのため、Swiftユーザーで無い人は、検査例外という言葉をみた瞬間に興味を失ってしまうため、その詳細がなかなか世の中に伝わっていないと感じています。一方、私はこんなSwiftのエラーハンドリングをとても気に入っていて、様々な言語の進化の歴史を踏まえた産まれた最も優れた最先端の仕様だと思っています。この記事ではその考えを説明します。 Javaのエラーハンドリング Javaは検査例外を持っています。これにより、あるメソッドがエラーを送出するかどうかを関数のシグネチャとして静的に表明できます。 // 検査例外の例
SwiftはどのようにJavaの検査例外を改善したか - Qiita
僕は、 Java の検査例外のコンセプトは素晴らしいと考えていますが、世間ではあまり好かれていないようです。 C# や Scala, Kotlin などの後続言語では採用されず、僕の知る限り Java 以降、検査例外（的なもの）を採用したメジャー言語は Swift だけです。 ただし、Swift の検査例外（的なもの）はいくつかの点で Java の検査例外と異なっています。 Swift は後続だけあって何かしらの改善を試みているわけです。その取り組みがおもしろいので、 Swift の検査例外的なものが Java の検査例外と何が違い、それがどのような意味を持つのかを紹介します。 throws 節でエラーの型を指定できない Java では
Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
これは 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 で発表した際にも参考文献にしまし
JavaScriptエンジニアなら知ってるよね？ エラー処理のいい書き方、悪い書き方
JavaScriptのエラー処理、ちゃんと書いていますか？ エラーを無視せず、どこに問題があるのか、きちんと確認できるコードの書き方をデモで紹介。 この記事はTim SeverienとMoritz Krögerが査読を担当しています。最良の記事を提供することができ、SitePointの査読担当者の皆さんに感謝します。 JavaScriptのエラー処理には危険が潜んでことを知っていますか？ もしマーフィーの法則を信頼しているとしたら、不具合が生じる可能性が本当に高いです！ この記事では、JavaScriptのエラー処理について考え、その落とし穴から便利な実践例までを説明します。さらに最後には、非同期コードとAjaxにも触れます。 JavaScriptはイベント駆動型プログラムで、プログラミングをより豊かなものにしてくれます。ブラウザーをイベント駆動型プログラムと考えると、発生するエラーは同一
Java 歴 23 分の Ruby エンジニアが Effective Java を読んで感動した話 - scramble cadenza
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
第２回目の Swift 2 シンポジウムも沢山の学びが得られる良い会でした。
今回で２回目となる Swift 2 シンポジウムに、今回はパネリストとして参加させて頂きました。 前回で大きな注目点は出尽くしたかと思っていたら、今回はさらに良質なテーマが掘り起こされて、たっぷりと楽しく議論できました。 実りもとっても大きかったです。
Swift 2.0 の Error Handling について考えてみる
Swift 2.0 の Error Handling ってどんな機会に使うんだろうと思いながら過ごしていたら、NSFileManager の contentsOfDirectoryAtPath:メソッド で縁があったので、そこから感じたことを記してみることにしました。 Swift 2.0 の Error Handling というのは、エラーの状況に応じて適切な回復手段を提供するための仕組みで、これまでの真偽値やオプショナルを使った方式のように、成功したか失敗したかだけでは物足りない場面をカバーできるもののようです。 また、NSError を使った Cocoa フレームワークのエラー処理を自然に扱えるようにデザインされたものという位置づけもあるようです。 Cocoa の Error Handling NSFileManager の contentsOfDirectoryAtPath: に見る
Swift 2.0 の try, catch ファーストインプレッション - Qiita
WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。本投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている（検査例外のような形） try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ
例外入門以前 - Qiita
例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根本的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。本当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ
例外設計の話
例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー
ブログを書くまでがjava-jaですが、もう眠いのでとりあえず1行だけ書いて、あとは徐々に書き足す。 会場を無料提供してくれたグリーさん、ありがとうございます！ 誰かが検査例外の話をするだろうと思って書かなかったら結局誰も言及しなかった、Javaのコミュニティなのに。 っていうか聴衆が100人もいると、もしかしてそもそも「検査例外ってなに？」って人もいたんじゃないか？「検査例外がOCPを壊す」とか「Liskovの置換原則のLiskov」とか通じてるんだろうか？とりあえず直和型が通じてないことだけはひしひしと感じた。 Twitterの自分の発言を転載しておく。 ちなみにZen of Pythonでも「エラーを握りつぶすな」と書いてあります 禅 of Python: 20の格言 「例外はそもそも何のため」ってところ、ざっくり省いたんだけどもそういうところのほうがニーズあったかね？？ 「C#1.
例外設計における大罪 - 契約
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
Haskell での例外処理 - あどけない話
リツイート数が30を超えたので、Haskell での例外処理について説明します。僕が思うに、Haskell での例外処理が分かりにくいのには、2つ理由があります。 ライブラリの混乱 パラダイムの違い 歴史的経緯により、Prelude にも Control.OldException にも Control.Exception にも catch があります。歴史的経緯を説明するのは面倒なので、これだけ覚えて下さい。「Control.Exception だけを使って、それ以外は忘れる」 そもそも純粋関数型で catch とか言われても分からないかもしれません。Haskell では、純粋な関数と IO とでは、例外処理の方法が異なります。命令的な catch などを使うのは IO です。純粋な関数には Maybe か、Either を使います。 純粋な関数 純粋な関数では、原則として例外を投げてはい
node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理) - kazuhoのメモ置き場
node.js を代表とする JavaScript を用いた非同期プログラミング環境においては、コーディングパターンのベストプラクティスが共有されておらず、結果として品質の低いコードが多くなるという問題があるように思います。そこで、特にエラー処理をどう書くべきか、既存のライブラリを使う方法を紹介してみることにしました。 いきなりですが、ファイルの文字数を返す関数を作ることを考えてみます。Java だと以下のような感じになるでしょうか。countChars メソッドに注目すると、エラーを例外として扱っていて、モジュラーかつ簡潔になっていることがわかります。 class FileCounter { static long countChars(String filename) throws IOException { FileInputStream is = new FileInputStre
コードレビューの視点 002: 柴田 芳樹 (Yoshiki Shibata)
必要なエラー情報を付加する何らかのエラーを検出した場合の対処方法としては、いくつかあります。 公開APIが呼ばれた場合のメソッドの引数の値が不正だった場合に、NullPointerExceptionやIllegalArgumentExceptionをスローしたりします。 デバッグ用にデバッグ文を表示したり、ログ情報を記録したりします。 コードレビューを行っていて気づく点としては、これらのエラーを通知してデバッグの助けとして書かれているコードが全く何の助けにもなっていないことが多いということです。 Javaでは慣例として、引数のnullの場合には、NullPointerExceptionをスローします（『Effective Java 第2版』 「項目60 標準例外を使用する」）。その場合、Javadocにその旨をきちんと記述すると同時に、例外をスローする際にエラー情報をコンストラクタのメッセ
Ruby の例外クラスは分類が粗すぎる or 細かすぎる - まめめも
と思いません？ def foo(x) end foo(1, 2) #=> wrong number of arguments (2 for 1) (ArgumentError) 1.step(10, 0) { } #=> step can't be 0 (ArgumentError) a = []; a << a a.flatten #=> tried to flatten recursive array (ArgumentError) 確かにどれも Argument に関する Error ではあるんだけど *1 、全部同じ例外クラスというのは粗すぎですよね。メッセージ読めば意味はわかるからデバッグには困りませんが、ArgumentError の中の特定の例外だけ拾いたいときに困ります。 具体的には、テストです *2 。例えば foo(1, 2) で wrong number of arg
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
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
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Java] SonOfAnException Handling in Try Multi-Catch?