C++ exceptions under the hood
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
Jestで非同期関数が例外を投げることをテストする。 - Qiita
背景 バイトで、Async関数が例外を投げてくれること、そしてその例外がどの例外であるかをテストする必要が出てきました。そのときのメモを残しておこうと思います。 やってみよう expectに関数を渡して、toThrowしてやると非同期でない関数が例外を投げるかどうかをテストできます。しかし、この場合、expectにAsync関数を渡しても期待どおりのテストを行うことはできません。 test('throws on octopus', () => { expect(() => { drinkFlavor('octopus'); }).toThrow(); }); 非同期処理が失敗したときに追加でアサーションを行うためには、rejectsを使います。この場合、Promiseが成功したときはアサーションが失敗します。 次のようなdrinkFlavorがあったとします。 async function
Default exception handler in Haskell
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
JavaScript でカスタム例外をしっかり使う
JavaScript には、そこかしこに罠がありますが、その中の1つはエラーハンドリングだと思います。 今回はエラーハンドリングにおいて、あまり活用されていない気がする、カスタム例外をしっかり使ってみたいと思います。 TL;DR necojackarc/extensible-custom-error を使うと、エラーオブジェクトも引数に取れる便利なカスタム例外が簡単に定義できるよ！ const ExtensibleCustomError = require('extensible-custom-error'); class MyError extends ExtensibleCustomError {} new MyError('message'); // メッセージ new MyError(error); // エラーオブジェクト new MyError('message', error
TypeScriptの異常系表現のいい感じの落とし所 | DevelopersIO
みなさんTypeScriptでサーバアプリケーション（Node.js）のロジックを書く時に、異常系の表現をどのようにされていますでしょうか？ここでいう異常系とは、仕様上想定される異常のことです。準正常系と言ったりもするかと思います。 私はJavaScriptの延長でTypeScriptをはじめたので、最初は null や undefined を返したり throw を用いるやり方をしていましたが、次第にTypeScriptが持つ型を生かし、できるだけ型安全に異常系を表現したいと考えるようになりました。そして試行錯誤した結果、いい感じの落とし所に落ち着いたので、その内容についてお伝えしたいと思います。 また記事の後半では、異常系の型を実装する中でハマった点についてもお伝えしたいと思います。 TypeScriptの異常系表現について 1. nullやundefinedを返す 冒頭でも述べたよう
Rust エラー処理2020 - 電気ひつじ牧場
このエントリは，Rust 3 Advent Calendar 2020の8日目の記事です． はじめに エラー処理の基本 Result<T, E> Errorトレイト ?オペレータ ベストプラクティスを支えるクレート anyhow thiserror failureクレートについて まとめ 追記 はじめに Rustを書いている時にアプリケーション固有のエラー型を定義したい場合があります．この辺のベストプラクティスは今まで何度か変化*1しており，今年の9月にエラーハンドリングのプロジェクトグループが発足*2したことからも分かるとおり，今後も変化していく可能性が濃厚です． この記事では，エラー処理まわりに関する基本的な内容と，現時点でのベストプラクティスとされているanyhowとthiserrorを用いたエラー処理について紹介します． エラー処理の基本 Result<T, E> Rustには例外
Timeout.timeout を安全に使うのは難しい | Wantedly Engineer Blog
こんにちは！Wantedly のエンジニアの縣です。 先日 Rails アプリケーションで ActiveRecord::StatementInvalid: PG::DuplicatePstatement というエラーが確率的に発生するという事象に遭遇し、その原因が Timeout.timeout と関係していてなかなか面白かったので記事に書き起こすことにしました。 （この記事を書くために今改めて調べてみたところ、 https://github.com/rails/rails/pull/41356 で ActiveRecord に関しては問題が解決していることがわかりました。が、記録として投稿しておきます。） TL;DRRuby の Timeout.timeout は非同期例外を発生させる非同期例外発生時に ActiveRecord の Connection の内部状態が壊れたことでエラーが
Try.do for recoverable errors in Haskell
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
Haskellの例外処理事情 - Qiita
Haskellを使うたびに例外について調べ直す癖がついているので、諸々をまとめておく。 TL;DR 部分関数を使うな。 失敗可能性はMaybe？Either？IO？ -> 迷ったらMonadThrowを使え。 予めエラー型を統一しないと例外処理クソだるいんだけど -> SomeExceptionを使え。 ライブラリどれ使えばいいの？ -> safe-exceptionsを使え。 部分関数を使うな 死の化身。部分関数自体を避けるしか方法はない。用意された部分関数を使う場合は必ずラップすること。 パターンマッチの失敗やundefined, error等のピュアな文脈での例外は、IOモナドの中でのみキャッチすることができる。しかし、ピュアな文脈で解決できる問題を神モナドで解決するのはあまり嬉しくない。ピュアなものはピュアなものに、神のものは神に返すべきである。 もし失敗をどの型で表すのか迷ったら
Swift 5.x のResultに備える - Qiita
Swift の機能提案は Swift Evolution で行われるのですが、 Swift の標準ライブラリに Result 型を追加するプロポーザル SE-0235 が承認されました。その結果、 Swift 5 で Result が標準ライブラリに追加されます。 本投稿では Result とは何か いつ Result を使うべきか Result をどのように扱うべきか 今のうちに Result に備える方法 を説明します。 Result とは何か Swift にはサードパーティ製の antitypical/Result という人気ライブラリがあり、 Result に馴染みのある人も多いと思います。本節では、 Result に馴染みのない人のために Result について簡単に説明します。 Result はエラーハンドリングに用いられる型で、次のように宣言されます。 public enum
Panic を恐れるべからず
Panic を恐れるべからず Rust で panic! や assert! の利用を躊躇うべきでないという話。 個人の見解マシマシでお送りします。 この記事は Rustその3 Advent Calendar 2019 の18日目の記事である[0]。 TL;DR 不正な値の存在の存在を許してはいけない。 不正な値が存在できてしまう時点で、未定義動作を覚悟するくらいのつもりでいるべきである。 満たされるべき条件を満たさない時点で、プログラムの内部的な整合性は既に破綻しており、未定義動作も同然の状態である。 これ以上余計なことをする前にさっさとクラッシュせよ。 整合性破壊バグから「うまく復帰」できると思うのは甘え (極論)。 もうちょっと詳しくは 本題、大雑把な指針、まとめ を参照。 いろいろな panic Rust で panic させるにも様々な方法がある。 まずはそれらを見ていこう。 O
kotlinのコードにReturn Resultを組み込む - nがひとつ多い。
はじめに 本記事は 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
段階的に理解する Java 例外処理 - Qiita
はじめに 例外処理の問題は Java コードレビューでの頻出指摘事項である。この記事で述べる通り、Java の例外処理において守るべき基本的なルールはそれほど複雑ではない。だが、たとえ職務経歴上は経験年数の長い Java プログラマであっても、適切な例外処理を実装できないケースは残念ながらよく観測される。さらに経験年数が短い Java プログラマにおいては言わずもがなである。 なぜ不適切な例外処理が広くはびこっているのか。そこには大きく分けて三つの要因が考えられる。まず、Java 言語仕様において例外機構 (特に検査例外) に歴史的事情による混乱があり、プログラマに過度の自由が与えられていることである。次に、アプリケーションを開発するだけでなく実際に運用してみない限り、不適切な例外処理の弊害に気づけないことである。最後に、適切な例外処理を学ぶためのコンパクトにまとまった資料が世に存在しない
「例外を投げない」という選択肢をとる言語 - Qiita
新しめの言語では例外を投げることを推奨しない言語が出てきているように思えるが、そうした言語が例外をどう考え、例外の代わりにどのようなアプローチを奨励しているかを調べてみた。 本稿での「例外」とは、Javaのthrow構文のようにスコープを脱出してcatchされるまでエスカレートされる「投げる例外」のことを指し、エラーを表現したオブジェクト(エラーオブジェクト)については「例外オブジェクト」と呼び区別するものとする。(この2つを同一に扱うと、例外を使わないということは、エラーオブジェクトは使わないの？という話になるため) Go言語 - 例外はコードを複雑にする Go言語では、通常、エラーは戻り値として扱われる。(本当の本当に例外的なエラーのためにpanic, recoverがあるが、ほとんど使われることがないように見受けられる。) 例外がないGoでは、どう呼び出し元にエラーを伝えているかとい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tc39/proposal-error-cause: TC39 proposal for accumulating errors
GitHub - Profpatsch/error: The canonical Haskell Error type
GitHub - kowainik/eio: 🎯 IO with Exceptions tracked on the type-level
Masking Asynchronous Exceptions
Maxim Koltsov blog
GitHub - expede/rescue: 🚒✨ Rescue: better errors through types (a more type directed MonadThrow/MonadCatch)