はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 …
その例外、いつキャッチするの？
はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と
明日から使える実践エラーハンドリング
class: center, middle # 明日から使える<br/><strong>実践</strong><br/>エラーハンドリング Scala関西Summit 2018 11/10 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value 代表取締役 * Opt Technologies 技術顧問 <img src="../images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> * F-CODE CTO <img src="../images/f-code_logo.png" alt="f-cod
My new error...
2023 年度の僕のエラーハンドリング について書きたい。 昨日Safe Data Fetching in Modern JavaScriptを読んでいて、fetch に限った話ではないが一家言ある内容だったので書きたくなった。 おそらくやりすぎだとか非効率と言われる点はあると思うので、みんなの一家言も教えて欲しい。 対象は Typescript での サーバー開発想定だが、TS であればクライアント開発にもほとんどに当てはまる話だと思う。 例外のスローではなく Result 型を使う Result は失敗するかもしれないという文脈を与えてくれる型 エラーハンドリングの戦略として例外を投げるのではなく、Result 型を返すやり方がある。 Result 型というのは export type Result<T, E> = Ok<T> | Err<E>; export interface Ok
【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
みなさんTypeScriptでサーバアプリケーション（Node.js）のロジックを書く時に、異常系の表現をどのようにされていますでしょうか？ここでいう異常系とは、仕様上想定される異常のことです。準正常系と言ったりもするかと思います。 私はJavaScriptの延長でTypeScriptをはじめたので、最初は null や undefined を返したり throw を用いるやり方をしていましたが、次第にTypeScriptが持つ型を生かし、できるだけ型安全に異常系を表現したいと考えるようになりました。そして試行錯誤した結果、いい感じの落とし所に落ち着いたので、その内容についてお伝えしたいと思います。 また記事の後半では、異常系の型を実装する中でハマった点についてもお伝えしたいと思います。 TypeScriptの異常系表現について 1. nullやundefinedを返す 冒頭でも述べたよう
JSF @rockfish31 「ウクライナ戦争を1日でも早く止めるために日本政府は何をなすべきか」 ロシア史研究者有志が声明発表 専門的見地から行動提起：長周新聞 chosyu-journal.jp/shakai/23102 長周新聞という媒体の時点でもう駄目なんだけど、「露悪玉論では出口なし」という内容の記事。現在の状況が全く見えてないんですね… JSF @rockfish31 成蹊大学名誉教授の富田武氏は、「日本の今の論壇やメディアでの説明や解説に非常に危ういものを感じる。防衛省関係者が増えたり、若手研究者でも危ない発言をしている人がいる。論調のかなりを占めているのが“ロシアはひどい国家だ”というものであり…」 つまり、現在の状況が気に入らないんですね？
Goとエラーハンドリング慣習について
エラー返値が無用な条件 関数ないしメソッドの実装がオンメモリ操作のみで完結 将来も（メモリ以外の）I/O操作は追加されることがない 逆にいうと上記の条件のいずれかが達成できない可能性がある関数やメソッドはエラー返値を付与すべき。 返値エラー型はerrorで統一する 返すエラーがerrorインターフェース型でなければそのエラーは正常にハンドリングできません。またerrorインターフェースを満たす別の返値型で返してerrorインターフェース型で受け取るのも後述のトラブルの元です。 Goの実装方針に「インターフェースで利用するものもコンストラクター相当では構造体ポインタで返す」というものがありますがコンストラクタを呼ぶ側は元型にアクセスすることが多いのでこういう方針になっています。が、エラー値に関しては元型を意識せずに利用可能にするという役割があって、この実装方針は当てはまりません。 エラーチェ
どうもエラーを出すもしくはエラーが出るのが怖いという人がいるみたい。例えば改修を行うときに既存部分でエラーが出ないことを最優先にして増築を行いいびつな構造を生み出すとか、単純に例外を全然使わないとか。エラーが出ると、「うわ、エラーになった。手間かけさせやがって面倒だなぁ…」みたいな感覚があって、とにかく自分がコードを書くときも一切例外を投げないというスタンスをとりがちなのかもしれない。 私はここで、適切にエラーが出てくれるのはむしろ喜ばしいことであり、自分がコードを書くときも積極的にエラーを出すようにすべきだ、という主張をする。 関数定義のドキュメンテーションの一部 ある関数の中身で一番最初に書くべき処理は何か、それは引数のチェックをして条件を満たさなければエラーを出すことである。例えば文字列は特定の形式になってなければならないとか、数値に最大値最小値があるとか、これらは関数の入力の前提条
リクルートアドベントカレンダーの20日目の記事です。 adventar.org 最初にこの疑問を思ったのは、今も忘れない R-ISUCON 2021 というリクルートの社内ISUCONの運営で炎上していた時の話です。 ちなみに R-ISUCON 2021 は劇的な結果で終わっているので、興味のある方は見てみてください。 blog.recruit.co.jp R-ISUCON 2021 では、 Node.js (TypeScript), Go, Java の3パターンの実装が出てくることが通例になっていまして、今回は Java の実装から Node.js, Go に適用していた時に一緒に実装していたメンバーからの疑問が『例外には色々な議論があるけれど、「例外を初めて実装した言語」ってどういう気持ちで実装したんだろう』という話が挙げられたので、そのネタを持ってきました。 ちなみにここで指してい
例外を投げるな、値を返せ
DroidKaigi.collect{ #1@Tokyo }（2023年3月31日）での発表資料です。
はじめに 6月に凄腕エンジニアさんから学んだ例外の話というQiita記事を書かせていただいたところ、かなり反響がありました。（2023年07月08日時点で570いいね、550ストック、はてなブックマークが560usersにブックマークされています） コメントなども目を通させていただいたところ、自分に基本的な例外の知識が足りないなと思ったので、いろいろな記事に目を通したり、本を読んだりして、インプットしました。 そのアウトプットとして今回記事を書きます。 エラーと例外 この記事ではエラーと例外という二つの概念は同じ概念で交換可能なものとして扱います。 （ソフトウェア設計のトレードオフと誤りより引用） Javaでは【プログラムではどうにもできない事態が起きた時に発生するものがエラー、そうではないものは例外】というような考え方があったり、他にも【想定内であれば例外、想定外であればエラー】という考
Exceptional Rails
kaigi on rails 2023での発表内容です https://kaigionrails.org/2023/talks/willnet/
このエントリは，Rust 3 Advent Calendar 2020の8日目の記事です． はじめに エラー処理の基本 Result<T, E> Errorトレイト ?オペレータ ベストプラクティスを支えるクレート anyhow thiserror failureクレートについて まとめ 追記 はじめに Rustを書いている時にアプリケーション固有のエラー型を定義したい場合があります．この辺のベストプラクティスは今まで何度か変化*1しており，今年の9月にエラーハンドリングのプロジェクトグループが発足*2したことからも分かるとおり，今後も変化していく可能性が濃厚です． この記事では，エラー処理まわりに関する基本的な内容と，現時点でのベストプラクティスとされているanyhowとthiserrorを用いたエラー処理について紹介します． エラー処理の基本 Result<T, E> Rustには例外
検査例外再考 - Qiita
検査例外はJavaで導入された例外に対する興味深い機構です。Javaで導入された当初、検査例外は多くの人々に素晴らしい解決策だと思われました。しかし、最近のメジャーなJVM言語で検査例外をサポートする言語はありません。JVM言語でなくとも、メジャー言語で検査例外をサポートするプログラミング言語は2014年現在1つとして存在しません*1。 何故検査例外は普及しなかったのでしょうか。結論から言えば、Javaの検査例外を用いた例外設計があまりにも難しく、ほとんどの組織にとって設計コストがペイ出来なかったためだと思われます。Javaの検査例外は例外というレイヤーで各々の処理を結びます。この時、別々の抽象度をある単一の例外で結んでしまうと、問題が発生します。つまり、抽象度の異なる処理同士を結びつけるたびに、その差異を吸収する独自例外表現が必要になります。この設計判断は不可能ではないものの、かなり難し
はじめに .NETのラムタイムからスローされる例外クラスのリファレンスに記述されている発生例のコードを参考に、サンプルコードをまとめてみました。本記事は以下の例外について記述してます。 例外 説明
Panic を恐れるべからず
Panic を恐れるべからず Rust で panic! や assert! の利用を躊躇うべきでないという話。 個人の見解マシマシでお送りします。 この記事は Rustその3 Advent Calendar 2019 の18日目の記事である[0]。 TL;DR 不正な値の存在の存在を許してはいけない。 不正な値が存在できてしまう時点で、未定義動作を覚悟するくらいのつもりでいるべきである。 満たされるべき条件を満たさない時点で、プログラムの内部的な整合性は既に破綻しており、未定義動作も同然の状態である。 これ以上余計なことをする前にさっさとクラッシュせよ。 整合性破壊バグから「うまく復帰」できると思うのは甘え (極論)。 もうちょっと詳しくは 本題、大雑把な指針、まとめ を参照。 いろいろな panic Rust で panic させるにも様々な方法がある。 まずはそれらを見ていこう。 O
Haskellの例外処理事情 - Qiita
Haskellを使うたびに例外について調べ直す癖がついているので、諸々をまとめておく。 TL;DR 部分関数を使うな。 失敗可能性はMaybe？Either？IO？ -> 迷ったらMonadThrowを使え。 予めエラー型を統一しないと例外処理クソだるいんだけど -> SomeExceptionを使え。 ライブラリどれ使えばいいの？ -> safe-exceptionsを使え。 部分関数を使うな 死の化身。部分関数自体を避けるしか方法はない。用意された部分関数を使う場合は必ずラップすること。 パターンマッチの失敗やundefined, error等のピュアな文脈での例外は、IOモナドの中でのみキャッチすることができる。しかし、ピュアな文脈で解決できる問題を神モナドで解決するのはあまり嬉しくない。ピュアなものはピュアなものに、神のものは神に返すべきである。 もし失敗をどの型で表すのか迷ったら
こんにちは！Wantedly のエンジニアの縣です。 先日 Rails アプリケーションで ActiveRecord::StatementInvalid: PG::DuplicatePstatement というエラーが確率的に発生するという事象に遭遇し、その原因が Timeout.timeout と関係していてなかなか面白かったので記事に書き起こすことにしました。 （この記事を書くために今改めて調べてみたところ、 https://github.com/rails/rails/pull/41356 で ActiveRecord に関しては問題が解決していることがわかりました。が、記録として投稿しておきます。） TL;DRRuby の Timeout.timeout は非同期例外を発生させる非同期例外発生時に ActiveRecord の Connection の内部状態が壊れたことでエラーが
Python例外処理 - Qiita
代表的な例外 TypeError 例：TypeError: unsupported operand type(s) for /: 'str' and 'int' String型を計算しようとしたときなどに起きるエラー ZeroDivisionError 例：ZeroDivisionError: division by zero 1/0のようにゼロで割ってしまったときに起きるエラー NameError 例：NameError: name 'hoge' is not defined 定義していない変数を使ったときに起きるエラー AttributeError 例：AttributeError: type object ‘list’ has no attribute 'fuga' 存在しない属性にアクセスしようとしたときに起きるエラー Pythonの例外処理ルール try: 括ったコードを例外処理
GitHub - tc39/proposal-error-cause: TC39 proposal for accumulating errors
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Advent Calendarへの招待、ありがとうございます。 本記事が何方かの役に立つことができると幸いです。 前書き すべての記事は、自分の勉強目的のため主観的な内容の整理を含まれています。あくまで参考レベルで活用してください。もし誤った情報などがあればご意見をいただけるととっても嬉しいです。 内容では省略するか曖昧な説明で、わかりづらいところもあると思います。そこは、連絡いただければ補足などを追加するので、ぜひ負担なくご連絡ください。 今回の記事は Java の Exception・Concept に起因した内容を一部含めています。Java と PHP のエラーの抽象化モデリングは少々違いがあるので、後述する内容は必ず PHP においての正解とは言えません。PHP の Exception に焦点をおくよりも、言語に関係なく Exception と Application においてのエ
Default exception handler in Haskell by Taylor Fausak on April 03, 2021 Have you ever wanted to install a default exception handler in Haskell? Until recently I didn’t think that was possible. Then I found Ivan Gromakovsky’s Handling of Uncaught Exceptions in Haskell blog post, which describes how to print exceptions using displayException rather than show. Ivan accomplishes that with a little kno
YAGNI exceptions
I'm essentially a believer in You Aren't Gonna Need It – the principle that you should add features to your software – including generality and abstraction – when it becomes clear that you need them, and not before. However, there are some things which really are easier to do earlier than later, and where natural tendencies or a ruthless application of YAGNI might neglect them. This is my collecti
UPDATE 2021-01-02: I have since written a GHC compiler plugin to implement an alternative ?-based syntax for early return. I prefer that one than use of Try.do, because it doesn’t require any type magic or special instances, and the ? is more readable. UPDATE: I’ve added a follow-up post to this here, where I address some criticisms of this post. The first half of this post is here. Please read th
はじめに クラス名，変数名，パッケージ名など，プログラミングには ”英語での命名” が不可欠ですよね． でも， こういうの，プログラミング的な英語ではなんて言ったらいいか分からない（適切な単語が思い浮かばない） そもそも日本語でもうまく命名できない など，困ったことはありませんか？ 僕自身，命名にはいつも悩まされますが，最近よく例外の命名についてとても悩んでしまします． たとえば 「データベースを検索した結果，該当するレコードが見つからなかった」という場合に投げる例外を考えます． Laravel の Eloquent Bulder を使う場合， というコードを書いたとき，id が 1 のユーザーが見つからなかった場合，ModelNotFoundException::class がスローされます． でも，もしこのような例外をを自分で考えないといけなかったとき， CouldNotFindMod
はじめに 本記事は Kotlin Advent Calendar 2019の１日目の記事です。 今回は前回当該ブログでも紹介しました、https://github.com/michaelbull/kotlin-resultについて事例をつけてご紹介させていただければと思います。 はじめに michaelbull/kotlin-resultの概要 どんなものなの 結果（OkかErr）によって処理をスマートに変える nullableな結果に対するエラーハンドリングもスマートに エラーに共通処理を実装してコードを簡素化に 例えthorwableな結果も安全に受け取ってエラーハンドルできる おわりに michaelbull/kotlin-resultの概要 github.com このgithubのイントロダクションが全てなのですが、 The Result monad has two subtype
Index A tiny ABI An ABI to appease the linker Catching what you throw Magic around __cxa_begin_catch and __cxa_end_catch Gcc_except_table and the personality function A nice personality Two-phase handling Catching our first exception _Unwind_ and call frame info Reading a CFI table And suddenly, reflexion in C++ Setting the context for a landing pad Multiple landing pads & the teachings of the gur
TL;DR PowerShellのエラーハンドリングには、Terminating ErrorとNon-Terminating Errorとに対するものがある。 try-catchによる処理の仕方や、Non-Terminating Errorの起こし方、これの捕まえ方などのサンプルコードをメモっておく。 はじめに 以前の投稿（PowerShellで例外を捕まえられない）で、PowerShellを実行したときに出る例外（正確には「例外っぽいエラー出力」）を捕まえるにはErrorActionパラーメタを渡すか$ErrorActionPreference変数で制御するかすればよい的なことを書いたけど、今回はもう少し丁寧にどういうことなのか調べてみた。 エラーの種類 Terminating ErrorとNon-Terminating Errorがある。カンタンにいうと、 Terminating Er
はじめに 自分は業務でC#を書いているのですが、今までかなりあやふやな知識で例外処理を使っていました。そこで、一度学びなおし、現時点での自分の中での「例外処理の利用方針」を固めておこうと思いました。 学びなおすために色々調べた結論としては、自分の知りたかった例外処理の利用方針は「++C++;」の「[雑記]例外の使い方」のページにとてもわかりやすくまとまっていました。 ただ上のページを読んだうえで自分の言葉でもまとめておきたかったので、上のページを大幅に参考にさせてもらいつつ、自分なりの解釈やコード例などを付け加えてまとめたのがこの記事となります。 この記事は個人の考えをまとめたものです。 この記事の内容はC#のバージョンについて特に意識していませんが、一部のコード例は古いバージョンのC#では使えない構文や機能を使っている可能性があります。 ++C++;で提案されている例外処理の利用方針 「
![[C#]例外処理の利用方針があやふやだったので、勉強しなおした - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2cf7764a2f808d92f783bd7f919ca7df1f3ddb1a/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCQyUyMyU1RCVFNCVCRSU4QiVFNSVBNCU5NiVFNSU4NyVBNiVFNyU5MCU4NiVFMyU4MSVBRSVFNSU4OCVBOSVFNyU5NCVBOCVFNiU5NiVCOSVFOSU4NyU5RCVFMyU4MSU4QyVFMyU4MSU4MiVFMyU4MiU4NCVFMyU4MSVCNSVFMyU4MiU4NCVFMyU4MSVBMCVFMyU4MSVBMyVFMyU4MSU5RiVFMyU4MSVBRSVFMyU4MSVBNyVFMyU4MCU4MSVFNSU4QiU4OSVFNSVCQyVCNyVFMyU4MSU5NyVFMyU4MSVBQSVFMyU4MSU4QSVFMyU4MSU5NyVFMyU4MSU5RiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YTlhODJiZDUwMTIxNmJjZTkwOTQ4NGM0MDA1MGMxN2E%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwS29zZWktWW9zaGlkYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTMyJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9N2Y3YzM3MDMxZDgyNjBjNzJiMDRmNWYzZWQ5NjNhN2U%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D72bf7b451a6f246c09d02a2e1217329e)
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
凄腕エンジニアさんから学んだ例外の話 - Qiita
TypeScriptの異常系表現のいい感じの落とし所 | DevelopersIO
「私はロシアに詳しいんだ」と称する人はだいたいソ連時代以来の老害らしい
エラーが出たら喜べ。エラーをちゃんと出せ。 - Qiita
例外を初めて実装した言語 - from scratch
ちょっと広く例外を学んでみた - Qiita
Rust エラー処理2020 - 電気ひつじ牧場
【C#】.NETからの例外エラーが発生するコードサンプル - Qiita
Timeout.timeout を安全に使うのは難しい | Wantedly Engineer Blog
PHP) Exceptionエラー設計原則とアプリケーションへの導入 - Qiita
Default exception handler in Haskell
Try.do for recoverable errors in Haskell
例外の命名の参考にするために Laravel の例外すべて漁ってみた
kotlinのコードにReturn Resultを組み込む - nがひとつ多い。
C++ exceptions under the hood
PowerShellでのエラー／例外処理について - Qiita
[C#]例外処理の利用方針があやふやだったので、勉強しなおした - Qiita