はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth
午後2時から行われた会見では、JAXAの岡田匡史氏（H3プロジェクトチームプロダクトマネージャ）が登壇し、経緯を説明。同氏によると、ロケットの自動カウントダウンシーケンスは予定通り開始され、メインエンジン「LE-9」が着火し正常に立ち上がったあと、ロケット下部（エンジン上部）に設置された1段制御用機器が異常を検知。SRB-3への着火信号を送らなかったことから、打ち上げ中止となった。なお、SRB-3側にも異常はなく、制御用機器が検知した異常そのものについては原因究明中という。 会見はJAXAの公式チャネルで配信されていたが、話題となったのが共同通信のとある記者の質問だ。「中止と失敗という問題についてもう一度確認したいです。ちょっともやもやするものですから」と切り出し、岡田氏に中止と失敗の違いについて質問した。以下はその一問一答だ。 共同 中止という言葉は、みなさんの業界でどう使われているかは
はじめに この記事では、メインフレームでは異常時の処理でどのようなことをやっているのか、また、Linuxの異常処理との違いなどについて話してみようと思います。 この記事を書くに至った直接的なきっかけは、とある人からリクエストがあったからです。が、日ごろからメインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多いと感じていてはいました。 筆者は今でこそLinux Kernel周りの仕事をしていますが、20年ぐらい前のころはメインフレームのOS開発部隊に配属されていて、メインフレームのとあるコプロセッサのドライバを書いたりしていました。この際、その異常処理における考え方を体験する機会が多々あり、当時のその経験が20年後の現在でも大いに役にたっていると感じていたからです。 そもそもメインフレームは、これまで長年にわたっ
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
明日から使える実践エラーハンドリング
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
【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
みなさんTypeScriptでサーバアプリケーション（Node.js）のロジックを書く時に、異常系の表現をどのようにされていますでしょうか？ここでいう異常系とは、仕様上想定される異常のことです。準正常系と言ったりもするかと思います。 私はJavaScriptの延長でTypeScriptをはじめたので、最初は null や undefined を返したり throw を用いるやり方をしていましたが、次第にTypeScriptが持つ型を生かし、できるだけ型安全に異常系を表現したいと考えるようになりました。そして試行錯誤した結果、いい感じの落とし所に落ち着いたので、その内容についてお伝えしたいと思います。 また記事の後半では、異常系の型を実装する中でハマった点についてもお伝えしたいと思います。 TypeScriptの異常系表現について 1. nullやundefinedを返す 冒頭でも述べたよう
Go のエラーハンドリング
私が Go のエラーハンドリングについて最初に記事にしたのは2015年のことだが，あれから Go も少しずつ変わってるし，私も当時よりは多少なりと理解が進んだと思うので，今まで書いた駄文を「全部入り」で本の形にしてみようと思う。 主な内容： * エラー評価の基本 * エラーの階層化 * サードパーティのパッケージ * ぼくがかんがえたさいきょうのえらーろぐ * Panic と Recover 寄付（サポート）歓迎。ご笑覧のほどを。
M 年前にも N 年後にも人類は同じ話をしている. まとめ エラーの発生方法は throw と return に大別できる throw には簡潔さ, return には明瞭さと型安全性といった特徴がある どちらの方法がより適しているかはプログラムの規模, エラーの種類, ハンドリングの方法などが判断の材料になる 実際にどちらの方法を使うかは上の判断材料と, フレームワークやプロジェクトのコーディング規約なども合わせて複合的に決めるのがよい エラー発生方法の分類 まず前提として, 関数から呼び出し元にエラーを伝える方法は以下の 2 つに大別できます. 逆にこの記事ではこれ以上の具体的な方法についての議論はしません. throw エラーを throw して呼び出し元に伝える方法です. 例えば以下のようなものが当てはまります. throw new Error("...") Promise.rej
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
TypeScript開発にRailway Orientedを持ち込み、より型安全なエラーハンドリングへ - Sansan Tech Blog
Digitization部 Bill One Entry*1グループの秋山です。 はじめに Domain Modeling Made Functionalというスゴ本 補講：Make Illegal States Unrepresentable バックエンドの処理を抽象化する 手続き型プログラミングの典型例 課題1：制約のないエラーハンドリング 課題2：低い可読性 課題3：エラーハンドリングの低い網羅性 Railway Oriented Programming TypeScriptで型安全にエラーハンドリングする ステップ1：サブ関数の出力はResult型で表現する ステップ2：サブ関数にResult型を入力できるようにする ステップ3：サブ関数を連結する ステップ4：網羅的にエラーハンドリングする おわりに 付録 TypeScriptの全文サンプル はじめに エラーハンドリングは重要な処
リクルートアドベントカレンダーの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 に適用していた時に一緒に実装していたメンバーからの疑問が『例外には色々な議論があるけれど、「例外を初めて実装した言語」ってどういう気持ちで実装したんだろう』という話が挙げられたので、そのネタを持ってきました。 ちなみにここで指してい
こんにちは、どんな作業もターミナルで行うことが多めの平野です。 最近はパイプに流すようなCLIアプリもPythonで作ることが多いので、 そこで必要になったいくつかの要素をまとめてみます。 パイプライン処理として実装しよう BrokenPipeの表示を消す argparseによる引数とオプションのパース この辺を考慮すれば、あとは文字列変換の主要なロジックだけを実装すればOKかと思います。 パイプライン処理として実装しよう パイプライン処理とだけ言うと色々な意味がありそうですが、ここで言っている意味は データの先頭行の処理の結果は最終行が入力される前でも取り出せるようにしよう ということです。 パイプ (コンピュータ)#シェルからの使用 - Wikipedia 複数行のテキストが入力されてきた時に、 それぞれの行の文字数をカウントするアプリケーションを作ったとします。 この時、以下のような
![[テンプレ付き]PythonでCLIツールを作るときのTips | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/47371cd63121a4cc67ed74841e706530c7e548f8/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F04%2Fpython.png)
例外を投げるな、値を返せ
DroidKaigi.collect{ #1@Tokyo }（2023年3月31日）での発表資料です。
Damien Neil and Jonathan Amsterdam 17 October 2019 Introduction Go’s treatment of errors as values has served us well over the last decade. Although the standard library’s support for errors has been minimal—just the errors.New and fmt.Errorf functions, which produce errors that contain only a message—the built-in error interface allows Go programmers to add whatever information they desire. All i
errors, fmt: add support for wrapping multiple errors · golang/go@4a0a2b3 · GitHub An error which implements an "Unwrap() []error" method wraps all the non-nil errors in the returned ... https://github.com/golang/go/commit/4a0a2b33dfa3c99250efa222439f2c27d6780e4a Go でエラーを扱う際に、複数のエラーを束ねたい事があります。例えば複数のタスクを実行し、1つでもエラーになれば中断するのではなく、一通りタスクを実施し終えた結果を返したい様なニーズです。 package main import ( "errors" "log" "os"
はじめに 6月に凄腕エンジニアさんから学んだ例外の話というQiita記事を書かせていただいたところ、かなり反響がありました。（2023年07月08日時点で570いいね、550ストック、はてなブックマークが560usersにブックマークされています） コメントなども目を通させていただいたところ、自分に基本的な例外の知識が足りないなと思ったので、いろいろな記事に目を通したり、本を読んだりして、インプットしました。 そのアウトプットとして今回記事を書きます。 エラーと例外 この記事ではエラーと例外という二つの概念は同じ概念で交換可能なものとして扱います。 （ソフトウェア設計のトレードオフと誤りより引用） Javaでは【プログラムではどうにもできない事態が起きた時に発生するものがエラー、そうではないものは例外】というような考え方があったり、他にも【想定内であれば例外、想定外であればエラー】という考
Stop catching errors in TypeScript; Use the Either type to make your code predictable
Stop catching errors in TypeScript; Use the Either type to make your code predictable In some languages such as Java, methods or functions can provide type information about the Exceptions or Errors they may throw. However in TypeScript, it is not possible to know what Errors a function may throw. In fact, a function could throw any value, even a string, number, object, etc. This is why TypeScript
Pythonには、オブジェクトにある名前の属性が存在するかどうかをチェックする hasattr という組み込み関数があります。 例えば、リストオブジェクトに append という属性が存在するかどうか確認するときは、次のようにかきます。 In [57]: L = [] print(hasattr(L, 'append')) print(L.append) True <built-in method append of list object at 0x7fbc80542d80> リストオブジェクトには append という属性が存在し、メソッドだということ
Haskellの例外処理事情 - Qiita
Haskellを使うたびに例外について調べ直す癖がついているので、諸々をまとめておく。 TL;DR 部分関数を使うな。 失敗可能性はMaybe？Either？IO？ -> 迷ったらMonadThrowを使え。 予めエラー型を統一しないと例外処理クソだるいんだけど -> SomeExceptionを使え。 ライブラリどれ使えばいいの？ -> safe-exceptionsを使え。 部分関数を使うな 死の化身。部分関数自体を避けるしか方法はない。用意された部分関数を使う場合は必ずラップすること。 パターンマッチの失敗やundefined, error等のピュアな文脈での例外は、IOモナドの中でのみキャッチすることができる。しかし、ピュアな文脈で解決できる問題を神モナドで解決するのはあまり嬉しくない。ピュアなものはピュアなものに、神のものは神に返すべきである。 もし失敗をどの型で表すのか迷ったら
インターネットでよく解説されているシンプルなコードは上のようなものだと思いますが、このコードをプロダクションで使用すると、対象のサーバーが応答しない場合フリーズしてしまう可能性があります。timeoutが設定されていない、つまり、最大で何秒待機すればよいか指定されていないからです。Webサービスの場合、待機中はユーザーに応答できなくなるので、本当は別の依存しているサーバーに責任があるのに、ユーザーにはあなたのWebサービスに問題があるように見えてしまうかもしれません。 Timeout を設定する必要性 ですから、timeout を設定しましょう。数秒待って応答が来なかったらエラーとして処理すればよいのです。 requests公式のドキュメントでもtimeoutを設定することが推奨されています。 Most requests to external servers should have a
getServerSideProps や API Routes で未認証リクエストを弾く方法はいくつかあります。例えば、公式では HOF（Higher-Order Function）を使った例が紹介されていて（withSession関数）認証要件ページで利用できるアプローチです。今回は別のアプローチとして、関数合成を用いたものを紹介します。 関数合成とは 現在 stage2 の Pipe Operator でご存じの方も多いと思いますが、reduce を使って複数の関数を合成するテクニックがあります。合成された関数はシリアルに実行され、戻り値が次関数の引数となり、演算することができます。例えば以下の例では、0 から順番に 100,200,300 と加算していき、最終的に 600 を得ることができます。 function pipeSync(...fns) { return (args) =>
Before getting started: no, there is no such thing as an async exception in Rust. I’ll explain what I mean shortly. Notice the comma in the title :). GHC Haskell supports a feature called asynchronous (or async) exceptions. Normal, synchronous exceptions are generated by the currently running code from doing something like trying to read a file that doesn’t exist. Asynchronous exceptions are gener
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 においてのエ
GitHub - cockroachdb/errors: Go error library with error portability over the network
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
打ち上げは「失敗」なのか「中止」なのか | 大塚実の取材日記
H3ロケット初号機の打ち上げ取材で種子島へ行ってきた。残念ながら、打ち上げは中止になってしまい、初フライトを見届けることはできなかったのだが、記事はすでにマイナビニュースに4本掲載しているので、そちらをご覧になって欲しい。 2年間待たされた新型ロケットがいよいよ打ち上げへ、現地の最新状況は？ 機体移動前に打ち上げの延期が決定、最短で17日へ 機体移動が正常に完了、日本最大のロケットがついに姿を現す 異常を検知し打ち上げは中止に、エンジン起動から約6秒の間に何が起きた？ ところで2月17日、打ち上げ中止後の記者会見において、某社の記者が「失敗」か「中止」かで執拗に食い下がり、「それは一般には失敗と言います。ありがとうございます」と捨て台詞まで残したことが大きな話題となった。その後、SNS上でも批判や擁護の声が入り交じっていて収拾が付いていないようなので、専門のライターとして、改めて少し考えて
Go の自作エラーを errors.Is と errors.As で wrap 元のエラーと識別するときには、Unwrap も実装しよう
概要 Go ではデフォルトのエラーに対して、自作エラーを作成して wrap するように有識者の間では推奨されています。 ただ、wrap すると本来のエラーが隠れてしまいテストや実行時に単純な比較ができなくなります。 そこで、よく紹介されるのが、errors.Isとerrors.Asです。 erros.Isとerrors.Asを使うと wrap 済みエラーに対して、元のエラーとの比較できます。 しかし、紹介記事では、そのままコピー&ペーストするとtrueを返してほしいときに、falseを返してしまう方法を散見します。 本記事では、間違えてしまうパターンについて紹介し、解決方法を紹介します。 元のエラーが不要で、wrap したエラーのみで比較する実装のときには、本記事の手順は不要になります。 うまく比較できないパターン 最初に、うまく比較できないパターンがどのようなときに発生するのか紹介します
throw expressionというRFCが投票中です。 最初のアイデアは2019/12/06のSebastiaan Andewegによるツイート。 Really liking the arrow functions in PHP 7.4 so far! Unfortunately already found one missing feature: you can't throw Exceptions from them. The following results in a 'unexpected T_THROW' syntax error: fn() => throw new Exception('nope'); Would've cleaned up my test, but alas. — Sebastiaan Andeweg (@sebandeweg) 2019年12月5日
Go: Multiple Errors Management
Illustration created for “A Journey With Go”, made from the original Go Gopher, created by Renee French.Error management in Go is always prone to debate and a recurrent topic in the annual survey about the biggest challenges developers are facing when using Go. However, when it comes to dealing with errors in a concurrent environment or combining multiple errors for the same goroutine, Go provides
20210404 Kotlin Tech Talk発表『例外ではなくnullを返すKotlinらしいAPIデザイン』
PHPの次期バージョンはこの時期どうなっているのか - Internalsの開発体制について - PHPカンファレンス小田原
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
例外クラスを自作して使用する Python コード例を書きました。 Python マニュアルによると、自作の例外は ユーザー定義例外ていぎれいがい (User-defined Exceptions) というようでした。 (Python) ユーザー定義例外 (User-defined Exceptions) 例外クラスの書き方は決まりきっていたので、とても簡単でした。 classクラス と書いて、 エラー名をつけて、 カッコの中に Exceptionエクセプション と書くだけです。 クラスの中身は無くてOKでしたので、passパス と書きます。 # 例外クラスを作ります。 class JisakuError(Exception): """自作プログラムのエラーを知らせる例外クラスです。""" pass # 例外クラスを使います。 raise JisakuError(f'数値がほしいのに No
An IOException wrapped in a ClientAbortException is thrown when a client closes the connection while its request is still being processed in the server. It is a little tricky to handle it in Spring MVC framework and I will explain how to do it in this post. Why is it tricky? We can handle exceptions in methods annotated with @ExceptionHandler. The first thought is after handling the exception, we
Googleスプレッドシート上で短縮URLを展開する[Google Apps Script] - あくぽろぐ aqpolog
ブログスモールスタート第3段。 やや前置き長め。 --目次-- Twitterでの情報収集 あとで読む（Pocket） あくぽろ流情報収集術 憎いt.co Googleスプレッドシート上で短縮URLを展開する[Google Apps Script] 今後の展望 Twitterでの情報収集 情報収集ツールとしてのTwitterはなんだかんだ優秀だと思っていて、 ニュースメディアのアカウントをフォローしておけば気になる記事を割とタイムリーに見ることができるし、 そうでなくても思いも寄らない情報をたまたまTL（タイムライン）で見つけた！みたいなこともまあまあよくある。 ※この辺は個人のフォローの仕方にもよるだろうけど… ただ、その場で読むまでもないかな、とか後でじっくり読もう、みたいな情報も結構ある。 そんなときに使われるのが公式ならいいね（かつてのFav）機能だし、 非公式クライアントなら「あ
![Googleスプレッドシート上で短縮URLを展開する[Google Apps Script] - あくぽろぐ aqpolog](https://cdn-ak-scissors.b.st-hatena.com/image/square/01eb540daaaf983289160ce6d187b3dd585c6949/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F6653458415127060667%2F10257846132605013398%2F1540546153)
PHPにおける独自例外設計を考える / A way to design user-defined exception with PHP
PHPカンファレンス沖縄2019の懇親会LTで話したPHPの独自例外、とくに独自基底例外クラスについてアイデアです
JavaやらPHPとかの例外処理をやっていたら、Delphiの例外処理って特殊というか、誤って理解している部分があったと認識しましたので、改めてまとめてみました。 Javaの例外処理 Javaの例外処理はスッキリしている（と思います）。 try { 例外が起きるかもしれない処理 } catch(AException e) { 例外AExceptionが発生した場合の処理 } catch(BException e) { 例外BExceptionが発生した場合の処理 } catch(CException | DException e) { 例外CExceptionかDExceptionが発生した場合の処理 } finally { 例外が起きても起きなくても行う処理 } tryブロックを抜けたら行う処理 catch節は、捕捉する例外に応じて続けることができます。finally節は、処理が不要なら
Help us understand the problem. What are the problem?
C++のthrow式はどんな型のオブジェクトであっても投げることができます。この是非は置いておいて、あるthrow式に対して適切にcatch節（例外ハンドラ）が用意されている場合に、呼び出される例外ハンドラは厳密にどのように決まるのでしょうか？なんとなくthrow式の引数と同じような型ならマッチする気はしますが、そのルールは関数のオーバーロード解決時のものとは異なる気がします。 catch節での型マッチング 例外ハンドラで使えない型 例外オブジェクトの型 例外オブジェクトの状態 例外ハンドラ引数の初期化 コピー省略が起こるところ 例外オブジェクトの寿命 std::exception_ptr 例 余談 : 決して選択されない例外ハンドラ 参考文献 catch節での型マッチング 例外オブジェクトの型をEとすると、対応する例外ハンドラの決定はそのcatch節の宣言型（以下、ハンドラの型）とEをマ
In this blog post, we examine the ECMAScript proposal “Error cause” (by Chengzhong Wu and Hemanth HM). It describes a feature where instances of Error can optionally specify that they were caused by another error. Why would we want to chain errors? # Sometimes, we catch errors that are thrown during a more deeply nested function call and would like to attach more information to it: function readF
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
凄腕エンジニアさんから学んだ例外の話 - Qiita
打ち上げ中止「H3」会見で共同記者の質問に批判相次ぐ ロケットを救った「フェールセーフ」とは
メインフレームの異常処理 - Qiita
Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
TypeScriptの異常系表現のいい感じの落とし所 | DevelopersIO
TypeScript エラー処理パターン - Object.create(null)
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
例外を初めて実装した言語 - from scratch
[テンプレ付き]PythonでCLIツールを作るときのTips | DevelopersIO
Working with Errors in Go 1.13 - The Go Programming Language
Big Sky :: errors.Join が入った。
ちょっと広く例外を学んでみた - Qiita
Pythonのhasattr()は遅い? - Atsuo Ishimoto's blog
【Python】requestsを使うときは必ずtimeoutを設定するべき
Next.js の非同期関数 piping と Error 設計
Async Exceptions in Haskell, and Rust - FP Complete
PHP) Exceptionエラー設計原則とアプリケーションへの導入 - Qiita
【PHP8.0】throw文がthrow式になる - Qiita
C++ exceptions under the hood
Python で例外を自作して使うコード例（ユーザー定義例外）
Spring - How to handle "IOException: Broken pipe"
Delphiの例外処理を理解する - Qiita
PHPで例外発生中に例外スローすると例外チェーンになる - Qiita
［C++］ 例外送出からキャッチまでのあいだ - 地面を見下ろす少年の足蹴にされる私
ECMAScript proposal: Error cause (chaining errors)