TypeScript エラー処理パターン - Object.create(null)
M 年前にも N 年後にも人類は同じ話をしている. まとめ エラーの発生方法は throw と return に大別できる throw には簡潔さ, return には明瞭さと型安全性といった特徴がある どちらの方法がより適しているかはプログラムの規模, エラーの種類, ハンドリングの方法などが判断の材料になる 実際にどちらの方法を使うかは上の判断材料と, フレームワークやプロジェクトのコーディング規約なども合わせて複合的に決めるのがよい エラー発生方法の分類 まず前提として, 関数から呼び出し元にエラーを伝える方法は以下の 2 つに大別できます. 逆にこの記事ではこれ以上の具体的な方法についての議論はしません. throw エラーを throw して呼び出し元に伝える方法です. 例えば以下のようなものが当てはまります. throw new Error("...") Promise.rej
Next.js の非同期関数 piping と Error 設計
getServerSideProps や API Routes で未認証リクエストを弾く方法はいくつかあります。例えば、公式では HOF（Higher-Order Function）を使った例が紹介されていて（withSession関数）認証要件ページで利用できるアプローチです。今回は別のアプローチとして、関数合成を用いたものを紹介します。 関数合成とは 現在 stage2 の Pipe Operator でご存じの方も多いと思いますが、reduce を使って複数の関数を合成するテクニックがあります。合成された関数はシリアルに実行され、戻り値が次関数の引数となり、演算することができます。例えば以下の例では、0 から順番に 100,200,300 と加算していき、最終的に 600 を得ることができます。 function pipeSync(...fns) { return (args) =>
ECMAScript proposal: Error cause (chaining errors)
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
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
Deno(Nodeでも)で外部モジュールのクラスやSymbolを使用するときは少し慎重になる必要がある
このとき、他のモジュールから持ってきた Error サブクラスは、本当に判定したいと思っているクラスであるかどうかを一考する必要があります。 deno-unknownutil という実際に存在するモジュールを使って説明していきます。以下のコードは実行できるようにしています。 ( deno v1.14.3 で確認 ) // mod1.ts import { ensureString } from "https://deno.land/x/[email protected]/mod.ts"; export const myCoolHandler = (get: () => unknown): string => { const v = get(); ensureString(v); return v.substring(1); }; // mod2.ts import { EnsureErr
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
Node.js Errors — Changes you need to know about
This post was written by Michael Dawson who is a Node.js Runtime Tech Dev @ IBM, #nodejs collaborator and CTC member. He originally posted this piece on the Nodejs @ IBM blog. SummaryChanges are coming to Errors thrown by the Node.js runtime. These changes started showing up in Node.js 8 and will continue to flow in during Version 9. This will impact any user whose code parses the message strings.
Rust Compiler Error Index
If you are not automatically redirected to the error code index, please here.
エラーを検査する - Qiita
NOTE: この記事は Inspecting Errors を翻訳したものです。 原文に従い、 Creative Commons ライセンスで公開します。 error インターフェイス型の値を返す関数の一般的な契約は、呼び出し側はその error をチェックする前にそれ以外のいかなる戻り値も利用してはいけないというものです。 多くのケースにおいて、関数が返した error 値は呼び出し元にとって不透明であるべきです。 error が nil かどうかチェックすることで呼び出しが成功したかどうかを知ることができ、そしてそれ以上のことはしません。 少ないケースにおいて、主にネットワークなどプロセス外の世界とやりとりする場合に、呼び出し側がエラーの種別を調べて、操作をリトライするべきかどうかを決める必要があります。 パッケージ作者に対して、呼び出し側がエラーの型を判別して利用できるように返すエラ
strawman:error_stack [ES Wiki]
All major browsers (if beta versions are included) now support accessing stack traces from scripts. However, no single browser agree on the details of how stack traces are accessible. function f() { try { doSomething(); } catch (err) { alert(err.stack) } } f(); Should alert something like: ReferenceError: doSomething is not defined at f (http://www.example.com/temp.html:5:5) at http://www.example.
例外 - Qiita Advent Calendar 2014 - Qiita
例外やエラー、それにまつわる各種言語の取り組み等を共有しましょう。 11月末までに書き手が集まらなかった場合は主催者による独りAdvent Calendarと化します。 集まらなかったので残念ながら独りAdvent Calendarと化しました。 追記 独りAdvent Calendarですが、以下の理由で頓挫しました。6日目以降はお好きにご活用ください。 http://qiita.com/Kokudori/items/3a953c00012408f76ab9#%E4%BE%8B%E5%A4%96-advent-calendar-2014%E3%81%AE%E7%B6%99%E7%B6%9A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
例外設計における大罪 - 契約
Grafana LokiではじめるKubernetesロギングハンズオン（NTT Tech Conference #4 ハンズオン資料）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tc39/proposal-error-cause: TC39 proposal for accumulating errors
Swiftのエラーハンドリングはなぜ最先端なのか - Qiita
https://hueniverse.com/learning-to-throw-again-79b498504d28