概要

TypeScriptでカスタムエラーの3つの実装方法を記載しました。
自分ならXXXなのでこれを選ぶ、あるいはもっといい方法があるというようなご意見をいただきたいです。

前提条件

Javascript(TypeScript)では極力例外を投げるのは避けるべきとは思っている
サポート対象ブラウザはChrome,FireFox,Safariの最新版のみ。デバイスはPC, タブレット, スマートフォン。
TypeScriptを使用したSPA. ソースコード50000行ほど、ファイル数680 今後2倍くらいになりそう
フロントエンド監視にはSentryを使用している
JavascriptのErrorを拡張して,エラー種別の判別とSentryでのバグトラッキングに活かしたい(エラーコードを設けたり、エラー種別によってエラーハンドリングを変えたり)

実装方法

1. Errorをimplementsするクラスを作成する

class ApplicationError implements Error {
    public name = 'ApplicationError';

    constructor(public message: string, public code: ApplicationErrorCode) { }

    toString() {
        return `${this.name}: ${this.message}`;
    }
}

出典 TypeScript実践プログラミング: p195

メリット

アプリケーションの例外とJSの例外が分別できる

引用:
ネイティブのError 型は聖域として扱い、この種の例外を決してスローしないようにしよう。
カスタム例外をApplicationError クラスのサブクラスとして作成すれば、本当に例外的な状況においてコードの外側で使用するためにError型を取っておくことができる。

デメリット

スタックトレースが取れない
子クラスを作るたびにnameを書かないといけない(何らかの方法で解決できるのかもしれないが自分は分からない)

2. Errorをextendsするクラスを作成する

class FooError extends Error {
    constructor(m: string) {
        super(m);

        // Set the prototype explicitly.
        Object.setPrototypeOf(this, FooError.prototype);
    }

    sayHello() {
        return "hello " + this.message;
    }
}

出典 Extending built-ins like Error, Array, and Map may no longer work

メリット

スタックトレースが取れる

デメリット

Object.setPrototypeOf を忘れたり誤ったりするとinstance instanceof FooErrorがfalseになる
TypeScript, Javascriptの仕様変更によって壊れる可能性が1より高い(実際にTypeScript2.1で壊れた)

3. Errorをカスタムするのではなく,throwをカスタムしてすべてErrorを使用する

/**
 * フレームワークエラーを発生させます。
 *
 * @private
 * @param code {Number} エラーコード
 * @param msgParam {Any[]} フォーマットパラメータ
 * @param detail {Any} 追加のデータ(内容はAPIごとに異なる)
 */
function throwFwError(code, msgParam, detail) {

        .....

	if (code) {
		e.code = code;
	}
	if (detail) {
		e.detail = detail;
	}

	throw e;
}

出典 hifive - HTML5企業Webシステムのための開発プラットフォーム - hifive

メリット

全てのエラーはErrorなのでインターフェースが統一されている
codeがenumであればdiscriminated unionsによって型の推論ができる

デメリット

TypeScriptだとグローバルのError型定義を拡張しなければならない
使用する側が気を付けなければならない

行動規範の内容に同意します

回答1件

ベストアンサー

https://teratail.com/questions/123768
から流れてきました。

１．のスタックトレースとれないのは割と痛いです。
３．の使用する側が注意するというのは複数人でやってるなら避けたいです。
ですので、２が良いかと思うのですが、これも他の人がsetPrototypeOf忘れるとか嫌だしinstanceofの継承関係がうまくできないので、独自abstractクラスを作ってそこから独自エラーを作ってもらう約束で、以下でどうでしょうか。

typescript
1abstract class MyProjectError extends Error {
2    constructor(m: string) {
3        super(m);
4        Object.setPrototypeOf(this, new.target.prototype);
5    }
6}
7class FooError extends MyProjectError {
8    constructor(m: string) { super(m); }
9}
10class BarError extends MyProjectError {
11    constructor(m: string) { super(m); }
12}
13
14let f = new FooError("a");
15let b = new BarError("a");
16console.log(f instanceof Error); // true
17console.log(f instanceof MyProjectError); // true
18console.log(f instanceof FooError); // true
19console.log(f instanceof BarError); // false
20console.log(b instanceof BarError); // true

TS2.2からつかえるnew.targetを使ってうまいことやってます。
TSリリースノート
new.targetはIE以外では動きそうですから大丈夫だと思います。
MDN new.target

破壊的修正によるリスクは依然としてありますが、ヒューマンエラーリスクは軽減していると思います。

setPrototypeOf自体利用を注意した方が良いとかErrorを聖域にすべきとか、その辺のべき論はちょっと分かっていないので、そこは自己判断いただければと思います。

投稿2018/04/27 04:48

退会済みユーザー

総合スコア0

退会済みユーザー

2018/04/27 06:12

`new.target` というものがあったのですね。これを使うと各子クラスで `Object.setPrototypeOf(this, ChildClass.prototype);` と毎回コンストラクタを宣言しなくても良くなるので、案2のデメリットがなくなりますね。勉強になりましたありがとうございます。

退会済みユーザー

2018/04/27 06:14

私もこの回答を通じて知りました。私も勉強になりました。

行動規範の内容に同意します