Typescript: 提案： `throws`句と型付きcatch句

明確にするために、ここでのアイデアの1つは、ユーザーに例外をキャッチさせるのではなく、catch句変数のタイプをより適切に推測することです。

@DanielRosenwasser
はい、ユーザーは例外をキャッチすることを強制されないので、これはコンパイラーで問題ありません（実行時にエラーがスローされます）：

function fn() {
    throw "error";
}

fn();

// and
try {
    fn();
} finally {
    // do something here
}

しかし、それは開発者にどの例外をスローできるかを表現する方法を提供し（他のライブラリ.d.tsファイルを使用するときにそれを持っていると素晴らしいでしょう）、コンパイラタイプにcatch句内の例外タイプを保護させます。

チェックスローはTried<Result, Error>とどのように異なりますか？

type Tried<Result, Error> = Success<Result> | Failure<Error>;
interface Success<Result> { kind: 'result', result: Result } 
interface Failure<Error> { kind: 'failure', error: Error }
function isSuccess(tried: Tried<Result, Error>): tried is Success<Result> {
   return tried.kind === 'result';
}
function mightFail(): Tried<number, string> {
}
const tried = mightFail();
if (isSuccess(tried)) {
    console.log(tried.success);
}  else {
    console.error(tried.error);
}

それ以外の

try {
    const result: Result = mightFail();
    console.log(success);
} catch (error: Error) {
    console.error(error);
}

@ aleksey-bykov

私のコードでthrowをまったく使用せず、代わりに結果を（エラーが発生する可能性のある関数で）ラップすることを提案しています。
このアプローチにはいくつかの欠点があります。

• このラッピングにより、より多くのコードが作成されます
• 呼び出された関数のすべてのチェーンがこのラップされた値（またはエラー）を返す必要があります。そうでない場合、 Tried<>を取得する関数はエラーを無視することを選択できません。
• これは標準のサードパーティライブラリではなく、ネイティブjsがエラーをスローします

throwsを追加すると、コード、3番目のライブラリ、ネイティブjsからのエラーを処理することを選択した開発者が有効になります。
提案ではエラーの推測も要求されるため、生成されたすべての定義ファイルにthrows句を含めることができます。
ドキュメントに移動する必要がある現在の状態ではなく、関数が定義ファイルから直接スローする可能性のあるエラーを知ることは非常に便利です。たとえば、 JSON.parseがスローする可能性のあるエラーを知る必要があります。 MDNページに移動し、次のように読みます。

解析する文字列が有効なJSONでない場合、 SyntaxError例外をスローします

そして、これはエラーが文書化されている場合の良いケースです。

そして、これはエラーが文書化されている場合の良いケースです。

SyntaxErrorとErrorを区別するための信頼できる方法がjavascriptにありますか？

• はい、それはより多くのコードですが、悪い状況はオブジェクトで表されるため、他の値と同じように、処理、破棄、保存、または有効な結果に変換するために渡すことができます

• tryも返すことでtryedを無視できます、tryedはモナドと見なすことができ、モナド計算を探します

  function mightFail(): Tried<number, string> {
  }
  function mightFailToo(): Tried<number, string> {
      const tried = mightFail();
      if (isSuccess(tried))  { 
           return successFrom(tried.result * 2);
      } else {
           return tried;
      }
  }
  

• これはコードにとって十分に標準的です。例外をスローするサードパーティのライブラリに関しては、例外から確実に回復することはほぼ不可能であるため、通常はゲームオーバーを意味します。理由は、コード内のどこからでもスローできるためです。任意の位置で終了し、内部状態を不完全または破損したままにする

• JavaScriptランタイムからのチェックされた例外はサポートされていません。また、typescriptだけで実装することはできません。

特別な結果の場合として例外をエンコードすること以外は、FPの世界では非常に一般的な方法です。

一方、考えられる結果を2つの部分に分割します。

• returnステートメントによって配信されたものと
• 別の投擲で配達

作り上げられた難しさに見えます

私の意見では、スローは、それについて何もできないときに速く大声で失敗するのに適しています。明示的にコード化された結果は、回復できる悪いが予想される状況を暗示するものに適しています。

検討：

// throw/catch
declare function doThis(): number throws string;
declare function doThat(): number throws string;
function doSomething(): number throws string {
    let oneResult: number | undefined = undefined;
    try {
        oneResult = doThis();
    } catch (e) {
        throw e;
    }

    let anotherResult: number | undefined = undefined;
    try {
        anotherResult = doThat();
    } catch (e) {
        throw e;
    }
    return oneResult + anotherResult;
}

// explicit results
declare function doThis(): Tried<number, string>;
declare function doThat(): Tried<number, string>;
function withBothTried<T, E, R>(one: Tried<T, E>, another: Tried<T, E>, haveBoth: (one: T, another: T) => R): Tried<T, R> {
    return isSuccess(one)
        ? isSuccess(another)
            ? successFrom(haveBoth(one.result, another.result))
            : another
        : one;
}
function add(one: number, another: number) { return one + another; }
function doSomething(): Tried<number, string> {
    return withBothTried(
        doThis(),
        doThat(),
        add
    );
}

@ aleksey-bykov

JSON.parseがSyntaxErrorをスローする可能性があるという私のポイントは、関数がスローされる可能性があることを知るために、ドキュメントで関数を調べる必要があるということです。 .d.tsでそれを確認する方が簡単です。
はい、 instanceof SyntaxErrorであることがわかります。

エラーをスローすることで、同じ悪い状況を表すことができます。
Errorを拡張する独自のエラークラスを作成し、必要なすべての関連データをそのクラスに入れることができます。
より少ないコードで同じ結果が得られます。

関数呼び出しのチェーンが長く、チェーンのさまざまなレベルでエラーの一部を処理したい場合があります。
常にラップされた結果（モナド）を使用するのはかなり面倒です。
言うまでもなく、とにかく他のライブラリとネイティブエラーがスローされる可能性があるため、モナドとtry / catchの両方を使用することになります。

私はあなたに同意しません。多くの場合、あなたは投げられたエラーから回復することができます、そして言語があなたがそれをよりよく表現することを可能にするならば、それはそうするのがより簡単でしょう。

typescriptの多くのものと同様に、javascriptの機能のサポートの欠如は問題ではありません。
この：

try {
    mightFail();
} catch (e: MyError | string) {
    if (e instanceof MyError) { ... }
    else if (typeof e === "string") { ... }
    else {}
}

タイプアノテーションなしで、javascriptで期待どおりに機能します。

throwを使用するだけで、あなたが言っていることを表現できます。操作が成功した場合は値を返し、そうでない場合はエラーをスローします。
次に、この関数のユーザーは、発生する可能性のあるエラーを処理するか、無視するかを決定します。
自分で投げたエラーのみを処理し、たとえばサードパーティのエラーは無視できます。

ブラウザについて話している場合、 instanceofは、同じウィンドウ/ドキュメントから発信されたものにのみ適しています。試してみてください。

var child = window.open('about:blank');
console.log(child.Error === window.Error);

だからあなたがするとき：

try { child.doSomething(); } catch (e) { if (e instanceof SyntaxError) { } }

あなたはそれをキャッチしません

それらが発生すると予想される場所をはるかに超えてコードに滑り込む可能性があるという例外を伴う別の問題

try {
   doSomething(); // <-- uses 3rd party library that by coincidence throws SyntaxError too, but you don' t know it 
} catch (e) {}

さらに、 instanceofはプロトタイプの継承に対して脆弱であるため、最終的な祖先を常にチェックするように特に注意する必要があります。

class StandardError {}
class CustomError extends StandardError {
}
function doSomething() { throw new CustomError(); }
function oldCode() {
   try {
      doSomething();
   } catch (e) {
      if (e instanceof StandardError) {
          // problem
      }
   }
}

@ aleksey-bykovモナディック構造で提案するように、明示的にエラーをスレッド化することは、非常に困難で困難な作業です。 それは多くの努力を要し、コードを理解するのを難しくし、言語サポート/タイプ駆動型のemitを耐えられるようにする必要があります。 これは、HaskellとFP全体の普及に力を入れている人からのコメントです。

これは、特に愛好家（私自身を含む）にとっては実用的な代替手段ですが、より多くの聴衆にとって実行可能な選択肢ではないと思います。

実際、ここでの私の主な懸念は、人々がエラーのサブクラス化を開始することです。 これはひどいパターンだと思います。 より一般的には、instanceof演算子の使用を促進するものはすべて、クラスの周りに追加の混乱を引き起こすだけです。

これは、HaskellとFP全体の普及に力を入れている人からのコメントです。

私は、これが消化されてより多くのことを求められるまでではなく、これを聴衆にもっと強く押し付けるべきだと本当に思います。言語でより良いFPサポートを得ることができますか？

すべてのコンビネータがすでに作成されている場合は、私たちのプロジェクトのように、それらを使用してデータフローを構築するだけで、思ったほど難しくはありませんが、TSがそれをより適切にサポートできた可能性があることに同意します：＃2319

モナド変換子は本物のPITAです。 あなたはかなり頻繁に持ち上げ、巻き上げ、そして選択的な走りをする必要があります。 最終的な結果は、ほとんど理解できないコードであり、必要な参入障壁よりもはるかに高くなります。 すべてのコンビネータとリフティング機能（必須のボクシング/アンボクシングを提供する）は、目前の問題からあなたをそらすだけのノイズです。 状態や効果などを明示することは良いことだと思いますが、便利なラッピング/抽象化はまだ見つかっていないと思います。 私たちがそれを見つけるまで、従来のプログラミングパターンをサポートすることは、その間に実験と探索をやめることなく進む方法のように思えます。

PS：カスタム演算子以上のものが必要だと思います。 実用的なモナディックライブラリには、より高度な型とある種の型クラスも不可欠です。 その中で、私は最初にHKTを評価し、次に型クラスを評価します。 そうは言っても、TypeScriptはそのような概念を実践するための言語ではないと思います。 いじくり回します-はい、しかしその哲学とルーツは適切なシームレスな統合のために根本的に遠いです。

OPの質問に戻る- instanceofは使用するのに危険な演算子です。 ただし、明示的な例外はErrorに限定されません。 独自のADTまたはカスタムPOJOエラーをスローすることもできます。 提案された機能は非常に便利であり、もちろん、かなり誤用される可能性もあります。 いずれにせよ、それは関数をより透明にします。これは間違いなく良いことです。 全体として、私はそれに50/50です:)

@ aleksey-bykov

開発者は、あなたが説明したさまざまなjsの問題に注意する必要があります。結局、typescriptにthrowsを追加しても、jsに新しいものは何も導入されず、言語としてのtypescriptに既存のjsの動作を表現する機能しか与えられません。

サードパーティのライブラリがエラーをスローする可能性があるという事実は、まさに私のポイントです。
彼らの定義ファイルにそれが含まれているとしたら、私はそれを知る方法があります。

@aluanhaddad
Errorを拡張するのはなぜひどいパターンなのですか？

@gcnew
instanceofについては、これは単なる例ですが、私はいつでも異なるタイプの通常のオブジェクトをスローし、タイプガードを使用してそれらを区別することができます。
スローしたいエラーのタイプを決定するのは開発者の責任であり、おそらくすでにそうなっていますが、現在、それを表現する方法はありません。これがこの提案で解決したいことです。

@nitzantomerネイティブクラスのサブクラス化（ Error 、 Array 、 RegExpなど）は、古いECMAScriptバージョン（ES6より前）ではサポートされていませんでした。 これらのクラスのダウンレベルの放出は予期しない結果をもたらし（最善の努力が払われますが、これは可能な限りです）、毎日多くの問題が記録される理由です。 経験則として、最近のECMAScriptバージョンをターゲットにしていて、実際に何をしているのかを理解していない限り、ネイティブをサブクラス化しないでください。

@gcnew
ああ、何が悪かったのかを理解するために数時間以上費やしたので、私はそれをよく知っています。
しかし、今はそうすることができるので、そうしない理由はないはずです（es6をターゲットにする場合）。

いずれにせよ、この提案は、ユーザーがErrorクラスをサブクラス化することを想定しておらず、単なる例にすぎません。

@nitzantomer提案がErrorに限定されていると主張しているわけではありません。 サブクラス化するのが悪いパターンである理由を説明しました。 私の投稿では、カスタムオブジェクトや識別された共用体も使用される可能性があるというスタンスを実際に擁護しました。

instanceofは危険であり、JavaScriptの特殊性を取り除いたとしても、アンチパターンと見なされます。たとえば、instanceof演算子に注意してください。 その理由は、コンパイラが新しいサブクラスによって導入されたバグからユーザーを保護できないためです。 instanceofを使用するロジックは壊れやすく、少数のオプションしか期待しないため、オープン/クローズの原則に従いません。 ワイルドカードケースが追加された場合でも、新しい派生物は、執筆時点での仮定に違反する可能性があるため、エラーを引き起こす可能性があります。

既知の選択肢を区別したい場合のために、TypeScriptにはタグ付き共用体（識別された共用体または代数的データ型とも呼ばれます）があります。 コンパイラーは、すべてのケースが処理されることを確認します。これにより、優れた保証が得られます。 欠点は、タイプに新しいエントリを追加する場合、それを識別するすべてのコードを調べて、新しく追加されたオプションを処理する必要があることです。 利点は、そのようなコードが壊れている可能性が最も高いことですが、実行時に失敗する可能性があります。

私はこの提案を考え直して反対になりました。 その理由は、 throws宣言が署名に存在するが、強制されていない場合、それらはドキュメントのコメントによってすでに処理できるためです。 強制された場合、JavaScriptには型付きcatch句に対するJavaのメカニズムがないため、イライラしてすぐに飲み込まれてしまうという感情を共有します。 例外の使用（特に制御フローとして）も、確立された慣行ではありませんでした。 これらすべては、チェックされた例外がもたらすものが少なすぎることを理解することにつながりますが、失敗を表すためのより優れた現在より一般的な方法が利用可能です（例：ユニオンリターン）。

@gcnew
これはC＃で行われる方法です。問題は、ドキュメントがtypescriptの標準ではないことです。
十分に文書化されている定義ファイルに出くわしたことを覚えていません。 さまざまなlib.d.tsファイルにはコメントが含まれていますが、スローされたエラーは含まれていません（1つの例外を除いて： lib.es6.d.tsにはDate[Symbol.toPrimitive](hint: string)に1つのthrowsがあります）。

また、この提案では、エラーの推測が考慮されています。これは、ドキュメントのコメントからエラーが発生した場合には発生しません。 推測されたチェック済み例外を使用すると、開発者はthrows句を指定する必要さえありません。コンパイラはそれを自動的に推測し、コンパイルに使用して、結果の定義ファイルに追加します。

エラー処理を強制することは良いことではないことに同意しますが、この機能を使用すると、必要な人が使用できる情報が追加されるだけです。
問題：

...失敗を表すためのより良いそして現在より一般的な方法があります

それを行うための標準的な方法がないということです。
ユニオンリターンを使用する場合があります。@ aleksey-bykovはTried<>を使用し、別のサードパーティライブラリの開発者はまったく異なることを行います。
エラーのスローは、言語（js、java、c＃...）全体の標準であり、システムの一部であり、回避策ではないため、（私の意見では）typescriptでの処理が優れているはずであり、その証拠はその数です。 catch句で型の注釈を要求する問題のいくつか。

関数（または呼び出された関数）がスローできる場合は、VSのツールチップに情報を入れたいと思います。 *.d.tsファイルの場合、TS2.0以降、おそらくこのような偽のパラメーターが必要になります。

@HolgerJeromin
なぜそれが必要になるのでしょうか？

ここに簡単な質問があります。以下のコードでdontCareに対してどの署名を推測する必要がありますか？

function mightThrow(): void throws string {
   if (Math.random() > 0.5) {
       throw 'hey!';
   }
}

function dontCare() {
   return mightThrow();
}

あなたがあなたの提案で言ったことによると、それは

function dontCare(): void throws string {

チェックされた例外が適切に処理されなかったため、タイプエラーである必要があると言います

function dontCare() { // <-- Checked exception wasn't handled.
         ^^^^^^^^^^

何故ですか？

そうしないと、直接の呼び出し元の状態が破損する可能性が非常に高くなるためです。

class MyClass {
    private values: number[] = [];

    keepAllValues(values: number[]) {
       for (let index = 0; index < values.length; index ++) {
            this.values.push(values[index]); 
            mightThrow();
       }
    }
}

例外をすり抜けさせた場合、 keepAllValuesの動作コントラクトに違反するため、チェック済みとして推測できません（元の意図にもかかわらずすべての値が保持されたわけではありません）

唯一の安全な方法は、すぐにそれらをキャッチし、明示的に再スローすることです

    keepAllValues(values: number[]) {
           for (let index = 0; index < values.length; index ++) {
                this.values.push(values[index]); 
                try {
                    mightThrow();
                } catch (e) {
                    // the state of MyClass is going to be corrupt anyway
                    // but unlike the other example this is a deliberate choice
                    throw e;
                }
           }
    }

そうしないと、発信者が何を盗むことができるかを知っているにもかかわらず、投げたばかりのコードを使用して続行しても安全であるという保証を彼らに与えることはできません

したがって、自動チェックされた例外契約の伝播などはありません。

私が間違っている場合は訂正してください。これはまさにJavaが行うことであり、前に例として説明しました。

@ aleksey-bykov
この：

function mightThrow(): void {
   if (Math.random() > 0.5) {
       throw 'hey!';
   }
}

function dontCare() {
   return mightThrow();
}

ただし、 mightThrowとdontCareの両方がthrows stringに推測されることを意味します。

function dontCare() {
    try {
        return mightThrow();
    } catch (e: string) {
        // do something
    }
}

エラーが処理されたため、 throw句はありません。
この：

function mightThrow(): void throws string | MyErrorType { ... }

function dontCare() {
    try {
        return mightThrow();
    } catch (e: string | MyErrorType) {
        if (typeof e === "string") {
            // do something
        } else { throw e }
    }
}

throws MyErrorTypeがあります。

あなたのkeepAllValuesの例については、あなたの例では、あなたが何を意味するのかわかりません。

class MyClass {
    private values: number[] = [];

    keepAllValues(values: number[]) {
       for (let index = 0; index < values.length; index ++) {
            this.values.push(values[index]); 
            mightThrow();
       }
    }
}

MyClass.keepAllValuesはthrows stringとして推測されます。これは、 mightThrowがstringをスローする可能性があり、そのエラーが処理されなかったためです。

あなたのkeepAllValuesの例については、私はあなたが何を意味するのかわかりません

mightThrow割り込みkeepAllValuesから処理されない例外が発生し、状態が破損したまま、実行中の途中で終了することを意味しました。 それは問題です。 あなたが提案するのは、この問題に目を閉じて、それが深刻ではないふりをすることです。 私が提案するのは、チェックされたすべての例外がすぐに処理され、明示的に再スローされることを要求することによって、この問題に対処することです。 このように、意図せずに状態を破損させる方法はありません。 そして、あなたがそうすることを選択した場合、それはまだ壊れている可能性がありますが、それはいくつかの意図的なコーディングを必要とします。

考えてみてください。例外については2つの方法があります。

• それらを処理しないと、クラッシュが発生します。クラッシュが必要な場合は、ここで問題ありません。
• クラッシュを望まない場合は、どのような種類の例外を探す必要があるかについてのガイダンスが必要です。ここで提案が出てきます。チェックされた例外-すべて明示的にリストされているので、すべてを処理して実行できます。何も見逃さない

ここで、適切に処理されてクラッシュを防ぐチェック済みの例外を使用することにした場合、キャッチしている場所のいくつかのレイヤーから発生する例外を処理するときの状況を除外する必要があります。

export function calculateFormula(input) {
    return calculateSubFormula(input);
}
export function calculateSubFormula(input) {
   return calculateSubSubFormula(input);
}
export function calculateSubSubFormula(input): number throws DivisionByZero  {
   return 1/input;
}

try {
   calculateFormula(0);
} catch (e: DivisionByZero) {
   // it doesn't make sense to expose DivisionByZero from under several layers of calculations
   // to the top level where nothing we can do or even know what to do about it
   // basically we cannot recover from it, because it happened outside of our immediate reach that we can control
}

上記の例は、考慮すべき興味深いケースをもたらします。推定される署名は次のとおりです。

function boom(value: number) /* what comes here?*/  {
    return 1/value;
}

別の興味深い事例

// 1.
function run<R, E>(callback(): R throws E) /* what comes here? */ {
    try {
        return callback();
    } catch (e: DivisionByZero) {
        // ignore
    }
}

function throw() { return 1 / 0; }

// 2.
run(throw); /* what do we expect here? */

@ aleksey-bykov
では、すべてのエラーをJavaの場合と同じように処理する必要があると提案しますか？
js / tsははるかに動的であり、ユーザーはそれに慣れているので、私はそのファンではありません（私はJavaから来て、まだそれを愛していますが）。
コンパイル時にエラーを含めると、エラーに対処するためのフラグになる可能性があります（ strictNullChecksなど）。

私の提案は、未処理の例外を解決するためのものではありません。投稿したコードは、この機能を実装しないと壊れてしまい、jsでも壊れてしまいます。
私の提案は、開発者として、スローされる可能性のあるさまざまなエラーをより認識できるようにするだけです。それらを処理するか無視するかは、まだあなた次第です。

ゼロ除算の問題については、エラーは発生しません。

console.log(1 / 0) // Infinity
console.log(1 / "hey!") // NaN

スローされる可能性のあるさまざまなエラーをよりよく認識します

彼らがそれらに対処できない限りそうする意味はありません、私がリストしたケースのために現在の提案は実行可能ではありません

では、すべてのエラーをJavaの場合と同じように処理する必要があると提案しますか？

はい、これは例外をチェックしたことの意味です

@ aleksey-bykov
あなたがリストしたケースのいずれかがこの提案を実行不可能にする理由がわかりません。

DivisionByZeroをスローすると推測された関数を使用している場合でも（スローされた場所に関係なく）、呼び出しチェーンのずっと下にスローされたエラーの処理に問題はありません。それを処理することを選択できます。 。
さまざまな引数を使用して再試行できます。問題が発生したというメッセージをユーザーに表示できます。この問題をログに記録して、後でコードを変更して処理できるようにすることができます（頻繁に発生する場合）。

繰り返しになりますが、この提案は実行時に何も変更されないため、機能したものはすべて以前と同じように機能し続けます。
唯一の違いは、スローされる可能性のあるエラーに関する詳細情報があることです。

私はあなたが言っていることを理解しています、javascriptの実行時に何も変更されませんが、ここでのあなたのメッセージは、ユーザーが20層下から来た例外を同じ自信を持って処理することによって彼らが何をしているかを知っているという幻想をユーザーに与えることです彼らは即時の例外を処理します

20層下で発生した問題を修正する方法はありません。

チェックされていない例外と同じように、ログに記録することはできますが、修正することはできません。

ですから、一般的に言って嘘です。TSには十分な嘘があります。人々をさらに混乱させないようにしましょう。

@ aleksey-bykov
あなたが説明していることは、例外をサポートするすべての言語に存在します。
例外をキャッチすることで問題が解決するとは誰も言いませんでしたが、問題を適切に処理できるようになります。

関数を呼び出すときにスローされる可能性のあるエラーを知ることは、開発者が処理できるエラーと処理できないエラーを区別するのに役立ちます。

今のところ、開発者はJSON.parseを使用するとエラーが発生する可能性があることを知らないかもしれませんが、それがlib.d.tsの一部であり、IDEが（たとえば）彼に通知する場合は、おそらく彼はこの場合を処理します。

内部状態が19層で破損しており、状態がプライベートであるためにそこに行くことができないため、20層下で発生した問題を適切に処理できません。

建設的であるために：私が提案しているのは、ユーザーがチェックされた例外をすぐに処理し、明示的に再スローすることを要求することです。このようにして、意図しない混乱を排除し、チェックされた例外をチェックされていないものから分離します。

• チェックされた例外：すぐに発生し、処理する必要があります。これにより、状態が破損しておらず、安全に続行できることが保証されます。
• 未チェックの例外：すぐ近くまたははるか下で発生しました。状態が破損しているため処理できません。ログに記録するか、自己責任で続行できます。

$＃$ JSON.parse $＃$のSyntaxErrorは、チェックされた例外として宣言する必要があります

@ aleksey-bykov

開発者に、彼らが望まないこと、彼らが今まで行っていないことをするように強制する必要がある理由がわかりません。

次に例を示します。
ユーザーがjsonデータを書き込んだり貼り付けたりして、ボタンをクリックできるWebクライアントがあります。
アプリはこの入力を受け取り、サードパーティのライブラリに渡します。サードパーティのライブラリは、このjsonを何らかの方法で解析し、さまざまなタイプの値（文字列、数値、ブール値、配列など）とともにjsonを返します。
このサードパーティライブラリがSyntaxErrorをスローした場合、回復できます。入力が無効であり、再試行する必要があることをユーザーに通知します。

関数を呼び出すときにスローされる可能性のあるエラーを知ることにより、開発者は処理できるものと処理したくないものを決定できます。
エラーがスローされたチェーンの深さは関係ありません。

あなたは私が言っていることを理解していないようです、私たちは輪になって行きます

サードパーティのライブラリからSyntaxErrorスローさせることで、カプセル化されているはずの独自のコードの実装の詳細にユーザーを公開します。

基本的にあなたは言っています、ねえ、それは私のコードではありません、それは私がインターネットで見つけて使用したその愚かなライブラリです、それであなたがそれに問題があるなら、私ではなくそのサードパーティのライブラリを扱ってください、私私が求められたことを言った

また、SyntaxErrorの後でそのサードパーティのインスタンスを引き続き使用できるという保証はありません。たとえば、スローした後にサードパーティのコントロールを再インスタンス化することにより、ユーザーに保証を提供するのはユーザーの責任です。

結論として、あなたは内部の例外を処理する責任を負う必要があります（それらのすべてではなく、チェックされたものだけです、お願いします）

私はあなたが言っていることを理解していますが、私はそれに同意しません。
そうです、それは基本的に私が言っていることです。
エラーをスローするサードパーティのライブラリを使用した場合は、それを処理するか無視して、コードのユーザーに処理させるかを選択できます。
これを行う理由はたくさんあります。たとえば、私が書いているlibはUIに依存しないため、何かが間違っていることをユーザーに通知することはできませんが、私のlibを使用する人は、使用時にスローされるエラーを処理できます。私のlibとユーザーと対話することによってそれらを処理します。

ライブラリがスローされたときに破損した状態のままになっている場合は、おそらくそれを文書化する必要があります。
その後、そのようなライブラリを使用し、その結果、エラーが発生した場合、状態が破損し、文書化する必要があります。

結論：
この提案は、スローされたエラーに関する詳細情報を提供するようになります。
開発者に別の方法で物事を行うように強制するべきではありません。必要に応じて、開発者がエラーに対処しやすくするだけです。

同意できない場合もありますが、問題ありません。チェックされた例外とは呼ばないでください。チェックされた例外とは異なるためです。

あなたが気にするのは開発者にそれらを認識させることだけなので、それらをリストされた、または明らかにされた例外と呼びましょう

@ aleksey-bykov
十分に公平で、名前が変更されました。

@ aleksey-bykov

内部状態が19層で破損しており、状態がプライベートであるためにそこに行くことができないため、20層下で発生した問題を適切に処理できません。

いいえ、内部状態を修正することはできませんが、ローカル状態を修正することはできます。これがまさにここでの処理のポイントであり、スタックの奥深くではありません。

例外を処理するときに一部の共有可変値がどのような状態にあるかを確認する方法がないという議論の場合、それは命令型プログラミングに反対する議論であり、この提案に限定されません。

すべてのレイヤーが、下のレイヤーからすぐに発生する例外に対応する責任を負う必要がある場合、正常に回復する可能性がはるかに高くなります。これは、チェックされた例外の背後にある考え方です。

別の言い方をすれば、1レベル以上下から来る例外は文であり、すべてのインフラストラクチャをゼロから再インスタンス化する以外のことを行うには遅すぎます（運が良ければ、グローバルな残り物はありません） tリーチ）

あなたの手の届かないところに何か悪いことが起こったという知識に反応する信頼できる方法がないので、述べられた提案はほとんど役に立たない

これは素晴らしい。 FWIW：追加された場合、デフォルトでスローメソッドを処理するか、メソッドにスローとしてマークを付ける必要があると思います。 それ以外の場合は、ほとんどドキュメントにすぎません。

@agonzalezjr
タイプスクリプトのほとんどの機能と同様に、この機能でもオプトインできるはずだと思います。
タイプを追加することが必須ではないのと同じように、スロー/キャッチする必要はありません。

--onlyCheckedExceptionsのように、それを必須にするフラグがあるはずです。

いずれにせよ、この機能は、ドキュメントのためだけでなく、スローされた例外のタイプを推測/検証するためにも使用されます。

@nitzantomer

次に例を示します。
ユーザーがjsonデータを書き込んだり貼り付けたりして、ボタンをクリックできるWebクライアントがあります。
アプリはこの入力を受け取り、サードパーティのライブラリに渡します。サードパーティのライブラリは、このjsonを何らかの方法で解析し、さまざまなタイプの値（文字列、数値、ブール値、配列など）とともにjsonを返します。
このサードパーティライブラリがSyntaxErrorをスローした場合、回復できます。入力が無効であり、再試行する必要があることをユーザーに通知します。

これは確かに、チェックされた例外の全体像が曖昧になる領域の1つです。 また、_例外的な状況_の定義が不明確になる場所でもあります。
この例のプログラムは、チェックされた例外をスローするものとして宣言されているJSON.parseの引数になります。
しかし、プログラムがHTTPクライアントであり、不正な形式の本文が含まれているHTTP応答に添付されたヘッダーの値に基づいてJSON.parseを呼び出している場合はどうなるでしょうか。 プログラムが回復するためにできる意味のあることは何もありません。プログラムができることは、再スローすることだけです。
これは、 JSON.parseがチェック済みとして宣言されることに反対する議論だと思います。

それはすべてユースケースに依存します。

これはフラグの下にあると提案されているとのことですが、この機能を使用したいと考えて、フラグを有効にしました。 私が書いているプログラムの種類に応じて、それは私を助けたり妨げたりするかもしれません。

従来のjava.io.FileNotFoundExceptionでさえ、この例です。 チェックされていますが、プログラムは回復できますか？ それは実際には、欠落しているファイルが呼び出し先ではなく呼び出し元にとって何を意味するかに依存します。

@aluanhaddad

この提案は、新しい機能を追加することを提案するものではなく、javascriptにすでに存在するものをtypescriptで表現する方法を追加することだけを目的としています。
エラーがスローされますが、現在、typescriptにはエラーを宣言する方法がありません（スローまたはキャッチする場合）。

あなたの例のように、エラーをキャッチすることによって、プログラムはこのエラーをキャッチすることによって「正常に」失敗する可能性があります（たとえば、ユーザーに「何かがうまくいきませんでした」メッセージを表示します）、またはプログラム/開発者によっては無視できます。
プログラムの状態がこのエラーの影響を受ける可能性がある場合、それを処理すると、壊れた状態ではなく有効な状態を維持できます。

いずれにせよ、開発者は、スローされたエラーから回復できるかどうかを確認する必要があります。
また、回復することの意味を決定するのも彼の責任です。たとえば、このhttpクライアントをサードパーティのライブラリとして使用するように作成している場合、ライブラリからスローされるすべてのエラーを同じタイプにすることができます。

enum ErrorCode {
    IllFormedJsonResponse,
    ...
}
...
{
    code: ErrorCode;
    message: string;
}

ここで、ライブラリでJSON.parseを使用して応答を解析するときに、スローされたエラーをキャッチしてから、独自のエラーをスローしたいと思います。

{
    code: ErrorCode.IllFormedJsonResponse,
    message: "Failed parsing response"
} 

この機能が実装されている場合、この動作を宣言するのは簡単であり、ライブラリのユーザーには、この機能がどのように機能し、失敗するかが明確になります。

この提案は、新しい機能を追加することを提案するものではなく、javascriptにすでに存在するものをtypescriptで表現する方法を追加することだけを目的としています。

知っている。 私はTypeScriptがこの提案の下で発するであろうエラーについて話している。
私の仮定では、この提案は、型チェックの目的でのみ、チェックされた例外指定子とチェックされていない例外指定子（推論または明示的）の区別を暗示していました。

@aluanhaddad

前のコメントであなたが言ったこと：

しかし、プログラムがHTTPクライアントであり、不正な形式の本文が含まれているHTTP応答に添付されたヘッダーの値に基づいてJSON.parseを呼び出している場合はどうなるでしょうか。 プログラムが回復するためにできる意味のあることは何もありません。プログラムができることは、再スローすることだけです。

関数が結果を返すように宣言されたときにnullを返す場合にも同じように適用されます。
開発者がstrictNullChecksを使用することを選択した場合、関数が（スローする代わりに） nullを返す場合、同じシナリオで「プログラムが実行できる意味のあるものは何もありません」とまったく同じことを言うことができます。回復する"。

ただし、 onlyCheckedExceptionsフラグを使用しなくても、この機能は引き続き役立ちます。たとえば、関数がErrorのみをスローするように宣言されているときに、エラーをstringとしてキャッチしようとすると、コンパイラが文句を言うからです。 Error 。

いいアイデアです。ネストされた呼び出しがあなたに何を投げかけるかを知る方法がないので、それは役に立ちますが、厳密/タイプセーフではありません。

つまり、タイプAの例外をスローする可能性のある関数があるが、その内部でネストされた関数を呼び出し、try catchに入れない場合、タイプBの例外が呼び出し元にスローされます。
したがって、呼び出し元がタイプAの例外のみを予期している場合、ネストされた例外から他のタイプを取得しないという保証はありません。

（スレッドが長すぎるので、このコメントを見逃した場合は申し訳ありません）

@shaipetel
命題は、コンパイラが未処理のエラーのタイプを推測し、それらを関数/メソッドのシグネチャに追加すると述べています。
したがって、あなたが説明した場合、 Bが処理されなかった場合、関数はA | Bをスローします。

ああなるほど。 呼び出すすべてのメソッドをドリルダウンして、考えられるすべての例外タイプを収集しますか？
可能であれば、それが起こるのを見たいです。 参照してください。開発者は、宣言されない予期しない例外を常に発生させる可能性があります。その場合、「オブジェクトがインスタンスに設定されていない」または「0で除算」、または同様の例外がほとんどすべての関数から常に発生する可能性があります。
私見では、すべての例外がメッセージを持つ基本クラスから継承され、ラップされていないテキストやその他のオブジェクトをスローすることをまったく許可しないC＃のように処理するのが最適でした。 基本クラスと継承がある場合は、キャッチをカスケードして、あるブロックで予想されるエラーを処理し、別のブロックで予期しないエラーを処理することができます。

@shaipetel
javascriptでは、すべてのエラーはErrorクラスに基づいていますが、エラーのスローに制限されているわけではなく、何でもスローできます。

• throw "something went wrong"
• throw 0
• throw { message: "something went wrong", code: 4 }

ええ、私はJavaScriptがどのように機能するかを知っています、私たちはさらなる制限を課すTypeScriptについて議論しています。
私が提案したのは、IMHOの良い解決策は、TypeScriptが例外処理に従うようにすることです。この例外処理では、スローされるすべての例外が特定の基本クラスであり、ラップされていない値を直接スローできないようにする必要があります。

したがって、「throw0」または「throw'someerror '」は許可されません。
JavaScriptが許可するのと同じように、TypeScriptは許可しません。

ありがとう、

@nitzantomer

関数が結果を返すように宣言されている場合にnullを返す場合にも同じことが適用されます。
開発者がstrictNullChecksを使用することを選択した場合、関数が（スローする代わりに）nullを返す場合、同じシナリオで「プログラムが回復するために実行できる意味はありません」とまったく同じことを言うことができます。

ただし、onlyCheckedExceptionsフラグを使用しなくても、この機能は引き続き役立ちます。たとえば、関数がErrorのみをスローするように宣言されているときに、エラーを文字列としてキャッチしようとすると、コンパイラが文句を言うからです。

私はあなたが言っていることを理解しています、それは理にかなっています。

@shaipetelは、この提案や他の場所で前述したように、 ErrorやArrayなどの組み込み関数のサブクラス化は機能しません。 これにより、広く使用されている実行時間とコンパイルターゲット間で異なる動作が発生します。

さまざまな非エラータイプの値をキャッチすることは、2つが提案された機能を想定する最も実行可能な方法です。 実際、この機能を利用する例外伝播メカニズムが、スタックトレースやその他のエラー固有のプロパティよりもはるかに具体的で、はるかに役立つエラーを引き起こす可能性があるため、問題としてはわかりません。
Errorを拡張することは実行可能ではありません。 es2015未満のすべてのターゲットが使用されなくなるまで実行できません。

この提案が間接的にError関数のサブクラス化につながる場合、それは悪い考えだと思います。 このような異議は、制御フローの例外の使用や例外的な状況の定義に関する哲学的な異議とは完全に別のものです。 したがって、この提案が採用された場合、正しい使用法とErrorのサブクラス化を回避する必要性に関する非常に大声であなたの顔のドキュメントを期待します。

型付き例外を処理するためのある種のヘルパーロジックがあることを望んでいます。async/ awaitを使用するために多くのpromiseコードをリファクタリングしています。これは現在次のようになっています。

doSomethingWhichReturnsPromise()
    .then(send(200))
    .catch(NotFoundError, (error) => { send(404); })
    .catch(SomeBadDataError, (error) => { send(400); })
    .catch(CantSeeThisError, (error) => { send(403); })
    .catch((error) => { send(500); })

次に、新しい世界では次のようになります。

{
    await doSomethingWhichReturnsPromise();
    send(200);
}
catch(error)
{
    if(error instanceof NotFoundError) { send(404); } 
    else if(error instanceof SomeBadDataError) { send(400); } 
    else if(error instanceof CantSeeThisError) { send(403); } 
    else { send(500); } 
}

これは問題ありませんが、より多くのコードが必要であり、いくつかの点で少し読みにくいので、次のサポートがあれば素晴らしいと思います。

{
    await doSomethingWhichReturnsPromise();
    send(200);
}
catch(NotFoundError, error) { send(404); }
catch(SomeBadDataError, error) { send(404); }
catch(CantSeeThisError, error) { send(404); }
catch(error) { send(404); }

これは前のビットを出力しますが、構文糖衣として、ジェネリックとしても実行できますが、少し厄介です。

{
    await doSomethingWhichReturnsPromise();
    send(200);
}
catch<NotFoundError>(error) { send(404); }
catch<SomeBadDataError>(error) { send(404); }
catch<CantSeeThisError>(error) { send(404); }
catch(error) { send(404); }

@grofit
typescriptがあなたの提案をサポートしてくれるならそれが欲しいのですが、私の意見ではこの問題とは関係ありません。
あなたが提案していることは、この問題が何であるかを実装せずに実装することもできます。コンパイラが（たとえば） NotFoundErrorがスローされないと文句を言うことができないというだけです。

これはタイプされたキャッチの提案であり、いかなる種類の問題でもないと思いました。スレッドを複製したくなかったので、それを独自の問題で投稿します。

@grofit
型指定されたキャッチも機能要求の一部ですが、関数からスローされる可能性のあるエラーのタイプをコンパイラーに通知する機能もあります（そして、コンパイラーはスローされる可能性のあるエラーのタイプを推測することもできます）。

私の意見では、タイプされたキャッチは他の部分なしで実装することができます。 新しい問題を開いてください、多分TSチームはそれを重複としてマークすることを決定するでしょう、私は知りません。

@grofit

これは前のビットを出力しますが、構文糖衣として、ジェネリックとしても実行できますが、少し厄介です。

try
{
  await doSomethingWhichReturnsPromise();
  send(200);
}
catch<NotFoundError>(error) { send(404); }
catch<SomeBadDataError>(error) { send(404); }
catch<CantSeeThisError>(error) { send(404); }
catch(error) { send(404); }

型のみに基づいてコードを生成することを意味するため、機能しませんが、

 doSomethingWhichReturnsPromise()
    .then(send(200))
    .catch(NotFoundError, (error) => { send(404); })
    .catch(SomeBadDataError, (error) => { send(400); })
    .catch(CantSeeThisError, (error) => { send(403); })
    .catch((error) => { send(500); })

いずれの場合もError関数を渡し、 instanceofで実装される可能性があります。 このようなコードは、非常に悪いことであるErrorの拡張を促進するため、有毒です。

@nitzantomer私はそれが別の問題であることに同意します。 OPには、 Errorを拡張しないタイプをキャッチする例があります。

@aluanhaddad
@grofitが要求することについては、次のようなことができます。

try {
    // do something
} catch (isNotFoundError(error)) {
    ...
}  catch (isSomeBadDataError(error)) {
    ...
} catch (error) {
    ...
}

isXXX(error)は、次の形式のタイプガードです。
function isXXX(error): error is XXX { ... }

@nitzantomerは確かですが、タイプガードは問題ではありません。 問題は

class MyError extends Error {
  myErrorInfo: string;
}

これは問題がありますが、すでにここで説明されています。 私は要点を詳しく説明したくありませんが、多くの大規模でよく知られているコードベースは、この貧弱な慣行を採用することによって悪影響を受けています。 Errorを拡張することは悪い考えです。

@aluanhaddad
私はそれを知っています。そのため、 @ grofitが要求したことを達成する方法を提供しましたが、 Errorを拡張する必要はありません。 開発者は必要に応じてErrorを拡張できますが、コンパイラはinstanceofを使用する必要のないjsコードを生成できます。

@nitzantomer私はあなたが知っていることを知っていますが、あなたが@grofitに提案していることを理解していませんでした。これはいい考えのように聞こえます。

そのようなパターンを使用させたいAPIを処理する必要がないため、私は死んだ馬を打ち負かしています。 とにかく、この議論を話題から外してしまったらごめんなさい。

この議論についてこれ以上考えたことはありますか？ typescriptでthrows句を見たいです。

@aluanhaddadあなたはErrorを拡張することは悪い習慣だと言い続けます。 これについて少し詳しく説明していただけますか？

それは長い間議論されてきました。 基本的に、組み込み型を確実に拡張することはできません。 動作は、環境と--target設定の組み合わせによって大幅に異なります。

私が尋ねた唯一の理由は、あなたのコメントが私がこれを最初に聞いたからです。 少しグーグルした後、 Errorを拡張する方法と理由を説明する記事しか見つかりませんでした。

いいえ、動作しません。 詳細については、 https：//github.com/Microsoft/TypeScript/issues/12123およびリンクされている多数の問題を参照してください。

それは機能しますが、ES6が適応されるにつれて大多数になりつつある「特定の環境」でのみ機能します。

@nitzantomer ： @throwsを含む関数が、周囲のtry/catchなしで呼び出されたときに、開発者に通知するTSLintチェックを実装することは可能だと思いますか？

@bennyn私はTSLintユーザーですが、新しいルールの作成を検討したことはありません。
それが可能かどうか（私はそうだと思いますが）、もしそうならどれほど簡単かは本当にわかりません。

やってみるなら、ここで更新してください、ありがとう。

@shaipetel （および@nitzantomer）

再：

ええ、私はJavaScriptがどのように機能するかを知っています、私たちはさらなる制限を課すTypeScriptについて議論しています。
私が提案したのは、IMHOの良い解決策は、TypeScriptが例外処理に従うようにすることです。この例外処理では、スローされるすべての例外が特定の基本クラスであり、ラップされていない値を直接スローできないようにする必要があります。
したがって、「throw0」または「throw'someerror '」は許可されません。
JavaScriptが許可するのと同じように、TypeScriptは許可しません。

これが@shaipetelの提案であるかどうかはわかりませんが、念のため... TypescriptでthrowをErrorのみを返すように制限しないように注意します。 Reactの今後の非同期レンダリング機能は、 throw ing Promiseによって内部で機能します！ （私が知っている奇妙に聞こえます...しかし、私は彼らがこれを彼らのユースケースのためにasync / awaitとyield / yield*ジェネレーターと比較して評価したことを読みましたそして私は彼らが何をしているのか知っていると確信しています！）

throw ing Error sは、99％のユースケースであると確信していますが、100％ではありません。 Typescriptは、ユーザーをthrow Error基本クラスを拡張するものだけに制限するべきではないと思います。 確かにはるかに高度ですが、 throwには、エラー/例外以外のユースケースがあります。

@mikeleonard
私は同意します、さまざまなタイプをスローする既存のjsコードの多くの例があります（私はたくさんのthrow "error message string"を見てきました）。
新しいReact機能はもう1つの良い例です。

ちょうど2セントで、コードをasync / awaitに変換しているので、スローされます（余談ですが、例外は嫌いです）。 私の意見では、この問題で説明されているようにthrows句を使用するとよいでしょう。 「投げる」が許されたとしても、それも役に立つと思います。 （また、デフォルトで「nothrows」に設定される「nothrows」およびコンパイラオプションもあります。）

関数がスローするものを入力できるようにするのは自然な拡張のようです。 戻り値はオプションでTSに入力できます。私には、throwは単なる別の種類の戻り値のように感じます（https://stackoverflow.com/a/39209039/162530のように、throwを回避するために提案されたすべての選択肢から明らかです）。

（個人的には、（オプションの）コンパイラオプションを使用して、スローとして宣言された関数の呼び出し元もスローとして宣言するか、キャッチする必要があることを強制したいと思います。）

私の現在のユースケース：[Angular]コードベース全体を変換して、エラー処理の例外を使用したくありません（私はそれらを嫌っています）。 APIの実装の詳細でasync / awaitを使用していますが、APIが戻ったときにthrowを通常のPromises / Observablesに変換します。 コンパイラーに、私が正しいものをキャッチしている（または、理想的にはそれらをキャッチしている）ことを確認してもらうと便利です。

@ aleksey-bykov JavaScriptの性質を変更するのではなく、JavaScriptに入力を追加するだけです。 :)

タイピングを追加すると、すでに変更されています（意味のないコードが切り取られます）。
同じように、例外処理を強化できます

2018年7月26日木曜日、午後8時22分にJoe [email protected]は次のように書いています。

@ aleksey-bykovhttps ：//github.com/aleksey-bykov変更しないでください
JavaScriptの性質上、タイピングを追加してみましょう。 :)

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/13219#issuecomment-408274156 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA5PzfUNS5E093Z74WA4WCUaTyWRRZC3ks5uKl1FgaJpZM4LXwLC
。

約束の場合、async / awaitの代わりにthenチェーンを使用し、 throwの使用を避けると、実際にはすべてが非常に美しく機能します。 概念実証スケッチは次のとおりです。

https://bit.ly/2NQZD8i-遊び場リンク

interface SafePromise<T, E> {
    then<U, E2>(
        f: (t: T) => SafePromise<U, E2>):
        SafePromise<U, E | E2>;

    catch<U, E2>(
        f: (e: E) => SafePromise<U, E2>):
        SafePromise<U, E2>

    catch<U, E1, E2>(
        guard: (e: any) => e is E1,
        f: (e: E) => SafePromise<U, E2>):
        SafePromise<U, Exclude<E, E1> | E2>
}

declare function resolve<T>(t:T): SafePromise<T, never>
declare function reject<E extends Error>(e:E): SafePromise<never, E>


class E404 extends Error {
    code:404 = 404;
}

class E403 extends Error {
    code:403 = 403;
    static check(e: any): e is E403 { return e && e.code === 403 }
}

let p = resolve(20)


let oneError = p.then(function f(x) {
    if (x > 5) return reject(new E403())
    return resolve(x)
})


let secondError = oneError.then(x => {
    if (x > 10) return reject(new E404())
    return resolve(x)
})

let remove403 = secondError.catch(E403.check, e => {
    return resolve(25)
})

let moreErrorsInfer = p.then(x => {
    if (x > 5) return reject(new E403())
    if (x > 10) return reject(new E404())
    return resolve(x)
})

let moreErrorsNoInfer = p.then((x):SafePromise<number, E403|E404> => {
    if (x > 5) return reject(new E403())
    if (x > 10) return reject(new E404())
    return resolve(x)
})

述語catchは型を和集合から削除し、 reject()を返すと型が追加されます。 うまく機能しないのは、ユニオンパラメータ型の推論だけです（おそらくバグ）

上記の例で対処された問題：

• エラーに限定されるものではなく、何でも拒否できます（おそらく悪い考えですが）
• instanceofの使用に制限されていないため、任意の述語型ガードを使用して、ユニオンからエラーを削除できます。

これをすべてのコードに使用することで私が目にする主な問題は、コールバックシグネチャです。互換性のある方法で機能させるために、デフォルトの「リターンタイプ」は「might-throw-any」になります。制限したい場合は、 throws Xと言います。 throws never

declare function pureMap<T>(t:T[], f: (x:T) => U throws never):U[] throws never

署名のないバージョン：

declare function dirtyMap<T>(t:T[], f: (x:T) => U):U[]

実際にはデフォルトで

declare function dirtyMap<T>(t:T[], f: (x:T) => U throws any):U[] throws any

現在のすべてのコードがコンパイルされることを保証します。

nullの戻り値が非常にまれであるstrictNullChecksとは異なり、JSの例外は非常に普及していると思います。 .d.tsファイルでそれらをモデル化することはそれほど悪くないかもしれません（エラーを説明するために依存関係から型をインポートします）が、それは間違いなく簡単な作業ではなく、巨大な結合をもたらします。

Promiseはすでにラッパーであり、非同期コードは通常のシナリオでエラー処理が最も分岐する場所であるため、Promiseとasync/awaitに焦点を当てることが適切な中間点になると思います。 その他のエラーは「チェックされていない」

@ spion-h4これは（すでに/今後）typescriptで使用できますか？

declare function dirtyMap<T>(t:T[], f: (x:T) => U throws any):U[] throws any

@bluelovers
いいえ、typescriptは現在throwsキーワードをサポートしていません。これが、この問題のすべてです。

注意すべき点は（必ずしもこの提案をブロックするわけではありません）、名詞クラスを入力しなくても、組み込みエラーはすべて構造的に同じであるため、特に有用ではないということです。

例えば：

class AnotherError extends Error {}

function* range(min: number, max: number): Iterable<number> throws TypeError, RangeError {
  if (typeof min !== 'number') {
    throw new TypeError('min must be a number')
  }
  if (typeof min !== 'number') {
    throw new TypeError('max must be a number')
  }
  if (!Number.isSafeInteger(min)) {
    // Allowed because without nominal types we can't distinguish
    // Error/RangeError/TypeError/etc
    throw new Error('min must be a safe integer')
  }
  if (!Number.isSafeInteger(max)) {
    // Also allowed because AnotherError is also structurally
    // compatible with TypeError/RangeError
    throw new AnotherError('max must be a safe integer')
  }
  for (let i = min; i < max; i++) {
    yield i
  }
}

@Jamesernator
この問題は提案とは何の関係もありません。
これを行うと、まったく同じ問題が発生する可能性があります。

class BaseClass {
    propA!: string;
}

class MyClass1 extends BaseClass { }

class MyClass2 extends BaseClass { }

function fn(): MyClass1 {
    return new MyClass2();
}

これは言語の制限であり、多くのユースケースに影響します。

型付き例外について@ahejlsbergによる素晴らしい読み物があります： https ：//www.artima.com/intv/handcuffs.html

TypeScriptは、これらの問題を回避するのに適した立場にあると思います。 TypeScriptは、_現実世界_の問題に対する_実用的な_ソリューションに関するものです。 私の経験では、大きなJavaScriptおよびTypeScriptコードベースでは、エラー処理は最大の問題の1つです。どのエラー関数がスローするか、処理したいかを確認するのは非常に困難です。 優れたドキュメントの読み取りと書き込み（この/ sがどれだけ優れているかは誰もが知っています）または実装を確認することによってのみ可能です。戻り値とは逆に、例外は関数呼び出しを介して自動的に伝播するため、直接呼び出された関数をチェックしますが、すべてをキャッチするには、ネストされた関数呼び出しもチェックする必要があります。 _これは現実の問題です_。

JavaScriptのエラーは、実際には非常に便利な値です。 NodeJSの多くのAPIは、明確に定義されたエラーコードを持ち、有用なメタデータを公開する詳細なエラーオブジェクトをスローします。 たとえば、 child_process.execFile()のエラーには$ exitCodeやstderrのようなプロパティがあり、 fs.readFile()のエラーにはENOENTのようなエラーコードがあります（ファイルが見つかりません）またはEPERM （不十分な権限）。 私はこれを行う多くのライブラリも知っています。たとえば、 pgデータベースドライバは、どの正確な列制約がINSERTの失敗を引き起こしたかを知るために、エラーに関する十分なメタデータを提供します。

エラーに適切なエラーコードがあり、それが何であるかを人々が認識していないため、コードベースのエラーメッセージに対して心配な量の脆弱な正規表現チェックを見ることができます。

@types宣言とlib.d.tsでこれらの関数がスローできるエラーを定義できれば、TypeScriptには、エラーの構造（発生する可能性のあるエラー、発生する可能性のあるエラー）を支援する力があります。エラーコード値は、それらが持つプロパティです。 これは型付き例外に関するものではないため、型付き例外に関するすべての問題を完全に回避します。 これは、_現実世界の問題_に対する_実用的な解決策_です（代わりにモナディックエラーの戻り値を使用するように人々に指示するのとは対照的に、JavaScriptランドの現実は異なって見え、関数はエラーをスローします）。

注釈は完全にオプションにすることができます（またはコンパイラフラグで必須にすることができます）。 宣言ファイルで指定されていない場合、関数は単にany （またはunknown ）をスローします。
関数は、 throws neverでスローしないように手動で宣言できます。
実装が利用可能な場合、関数は、呼び出す関数のすべての例外タイプと、 catchのあるtryブロック内にない独自のthrowステートメントの和集合をスローします。 catch句。
それらの1つがanyをスローすると、関数もanyをスローします。これは問題ありません。すべての関数境界で、開発者は明示的なアノテーションを使用して修正する機会があります。
そして、多くの場合、単一のよく知られた関数が呼び出され、try / catchでラップされます（たとえば、ファイルを読み取り、それが見つからない場合は処理します）。TypeScriptはcatch句の型を推測できます。

このためのエラーサブクラス化もinstanceofも必要ありません-エラータイプは、文字列リテラルでエラーコードを指定するインターフェイスにすることができ、TypeScriptはエラーコードの和集合を識別したり、タイプガードを使用したりできます。

エラータイプの定義

interface ExecError extends Error {
  status: number
  stderr: Buffer
}
function execFileSync(cmd: string): Buffer throws ExecError;

interface NoEntityError extends Error { code: 'ENOENT' }
interface PermissionError extends Error { code: 'EPERM' }
function readFileSync(file: string): Buffer throws NoEntityError | PermissionError;



md5-818797fe8809b5d8696f479ce1db4511



Preventing a runtime error due to type mismatch



md5-c2d214f4f8ecd267a9c9252f452d6588



Catching errors with type switch



md5-75d750bbe0c3494376581eaa3fa62ce5



```ts
try {
  const resp = await fetch(url, { signal })
  if (!resp.ok) {
    // inferred error type
    // look ma, no Error subclassing!
    throw Object.assign(new Error(resp.statusText), { name: 'ResponseError', response })
  }
  const data = await resp.json()
} catch (err) { // AbortError | Error & { name: 'ResponseError', response: Response } | SyntaxError
  switch (err.name)
    case 'AbortError': return; // Don't show AbortErrors
    default: displayError(err); return;
  }
}



md5-a859955ab2c42d8ce6aeedfbb6443e93



```ts
interface HttpError extends Error { status: number }
// Type-safe alternative to express-style middleware request patching - just call it (TM)
// The default express error handler recognises the status property
function checkAuth(req: Request): User throws HttpError {
    const header = req.headers.get('Authorization')
    if (!header) {
        throw Object.assign(new Error('No Authorization header'), { status: 401 })
    }
    try {
        return parseHeader(header)
    } catch (err) {
        throw Object.assign(new Error('Invalid Authorization header'), { status: 401 })
    }
}

エラーとは別に、次のような他の種類の副作用をマークすることも可能ですか？

• 発散（無限ループ/戻らない）
• IO
• 非決定論（ Math.random ）

戻り型への影響にタグを付けることができるMSRのKokaを思い出させます。

提案：

function square(x: number): number &! never { // This function is pure
  return x * x
}

function square2(x : number) : number &! IO {
  console.log("a not so secret side-effect")
  return x * x
}

function square3( x : number ) : number &! Divergence {
  square3(x)
  return x * x
}

function square4( x : number ) : number &! Throws<string> { // Or maybe a simple `number &! Throws`?
  throw "oops"
  return x * x
}

function map<T, R, E>(a: T[], f :(item: T) => R &! E): R[] &! E { ... }
function map<T, R>(a: T[], f :(item: T) => R): R[] { ... } // will also work; TS would collect side effects

function str<T>(x: T): string &! (T.toString.!) // care about the side effect of a type

エラータイプの宣言のアイデアが大好きです！ これは、それを必要とする人々にとって大きな助けとなり、それを嫌う人々にとって悪いことは何もしません。 ノードプロジェクトに問題が発生しました。この機能を使用すると、より迅速に解決できます。 エラーをキャッチして適切なhttpコードを返送する必要があります-そのためには、処理する必要のある例外を見つけるためにすべての関数呼び出しを常にチェックする必要があります-これは楽しいことではありません-_-

PS。 https://github.com/Microsoft/TypeScript/issues/13219#issuecomment -428696412の構文は非常に見栄えがよく、 &!とエラータイプを<>でラップするのは驚くべきことです。

私もこれに賛成です。 現在、すべてのエラーは型指定されておらず、それはかなり厄介です。 ほとんどのthrowsがコードisoから派生できることを願っていますが、どこにでも記述しなければなりません。

このようにして、開発者が残りのエンドポイントなどでユーザーにわかりにくいエラーをキャッチするように強制するtslintルールを作成することもできます。

私は実際、この機能がTypeScriptの中に_すでに_含まれていないことに驚いていました。 私が最初に宣言したことの1つ。 スローされたエラーが発生し、どのタイプのエラーがスローされるかという情報を取得できる限り、コンパイラーがそれを強制するかどうかは問題ありません。

&!を取得せず、 Throws<T>を取得したとしても、：+ 1：になります。

これはまさに私が念頭に置いていることです。TypeScriptがこれらの句をサポートしていれば、はるかに美しいでしょう。

もう1つの可能な機能は、何らかの方法で（おそらく関数レベルまたはモジュールレベルで）strictExceptionTrackingを強制することです。これは、式try! invokeSomething()を使用してthrows Xとして宣言されたものを呼び出す必要があることを意味します。 Rustとswiftのように。

単純にinvokeSomething()にコンパイルされますが、例外の可能性がコードに表示されるため、一時的な状態が悪い場合に変更可能なものを残している（または割り当てられたリソースを破棄しない）場合に簡単に見つけることができます。

@ be5invis

function square(x: number): number &! never { // This function is pure
  return x * x
}
...

私はここで2セントを与えているだけですが、 &!は私には信じられないほど醜いように見えます。
タイプスクリプトに不慣れな人は、この記号に見捨てられると思います。それは本当に魅力的ではありません。
私の意見では、単純なthrowsは、より明確で、直感的で、単純です。

それ以外は、型付き例外の場合は+1。 👍

入力およびチェックされた例外の+1を追加したいと思います。
コードで型付き例外をうまく利用しました。 私はinstanceofの落とし穴を十分に認識しています。実際には、共通の基本クラスから継承する関連エラーの汎用ハンドラーを記述できるため、これを有利に使用しています。 基本のErrorクラスからの継承を回避するために私が遭遇した他のほとんどのメソッドは、（少なくとも）同じように複雑で、さまざまな点で問題があります。
チェックされた例外は、私の意見では、コードベースに対する静的分析の洞察を深めるのに役立つ改善です。 十分に複雑なコードベースでは、特定の関数によってスローされる例外を見逃しがちです。

typescriptでコンパイル時のエラーの安全性を探している人は、私のts-resultsライブラリを使用できます。

残念ながら、 @ vultixは、これをチーム設定に入れるのに十分なほど明確ではありません。

@vultix libのアプローチについては上記で説明しましたが、この機能が解決する方法とは正反対です。
Javascriptにはすでにエラーを処理するメカニズムがあり、例外と呼ばれていますが、typescriptにはそれを説明する方法がありません。

@nitzantomer私はこの機能がtypescriptの必需品であることに完全に同意します。 私のライブラリは、この機能が追加されるまでの一時的な代役にすぎません。

function* range(min: number, max: number): Iterable<number> throws TypeError, RangeError {

私はこれについてこのゲームに少し遅れていることを知っていますが、以下はコンマではなく、もう少しTypescripty構文のようです。

Iterable<number> throws TypeError | RangeError

しかし、私はまだコンマが得意です。言語でこれがあればいいのにと思います。
主なものは、 JSON.parse()で欲しいです。なぜなら、私の同僚の多くは、 JSON.parseがエラーをスローする可能性があることを忘れているようで、プルリクエスト。

@WORMSS
同意します。
私の提案には、あなたが推奨する構文が含まれていました。

function mightThrow(): void throws string | MyErrorType { ... }

JavaのようなOOP言語のエラー宣言パターンに従うことはできますか？ 「throws」キーワードは、潜在的なエラーのある関数を使用するときに「try..catch」が必要であることを宣言するために使用されます

@allicanseenow
提案は、throws句のオプションの使用法です。
つまり、スローする関数を使用している場合は、try / catchを使用する必要はありません。

@allicanseenowリンクされた記事を含め、コンテキストについて上記の私の記事を読むことをお勧めします： https ：//github.com/microsoft/TypeScript/issues/13219#issuecomment -416001890

これはtypescript型システムに欠けているものの1つだと思います。
その純粋にオプションで、発行されたコードを変更せず、ライブラリとネイティブ関数の操作に役立ちます。

また、どのエラーがスローされる可能性があるかを知っていると、編集者はif条件を使用してcatch句を「オートコンプリート」してすべてのエラーを処理できます。

つまり、実際には小さなアプリケーションでも適切なエラー処理に値します。現在の最悪の事態は、ユーザーがいつ問題が発生するかわからないことです。

私にとって、これは現在、TOPに欠けている機能です。

@RyanCavanaugh 、「Awaiting MoreFeedback」ラベルが追加されてからたくさんのフィードバックがありました。 タイプスクリプトチームのメンバーは参加できますか？

@nitzantomer TypeScriptにスローを追加するというアイデアはサポートしていますが、オプションのtry / catchを使用すると、ネストされた関数でスロー宣言が不正確になる可能性がありますか？

開発者がメソッドのthrows句が正確であると信頼するには、そのメソッドの呼び出し階層のどの時点でもオプションの例外が無視され、報告されずにスタックがスローされるという危険な仮定を立てる必要があります。 @ajxsは彼のコメントの最後でそれをほのめかしたかもしれないと思いますが、これは大きな問題になると思います。 特に、ほとんどのnpmライブラリがどれほど断片化されているかについて。

@ConnorSinnott
私はあなたを正しく理解していることを願っています：

コンパイラは、スローされた型を推測します。次に例を示します。

function fn() {
    if (something) {
        throw "something happened";
    }
}

実際にはfunction fn(): throws string { ... }になります。
宣言されたエラーと実際のエラーの間に不一致がある場合にも、コンパイラはエラーになります。

function fn1() throws string | MyError {
    ...
}

function fn2() throws string {
    fn1(); // throws but not catched

    if (something) {
        throws "damn!";
    }
}

コンパイラは、 fn2が$ string string | MyError $をスローすることを文句を言う必要があります。

このすべてを念頭に置いて、この仮定が、他のライブラリやフレームワークなどを使用するときに開発者が信頼する他の宣言された型の仮定よりも危険であるとは思いません。
すべてのオプションを実際にカバーしたかどうかはわかりません。興味深いシナリオを考え出していただければ幸いです。

そして、この問題があっても、それはとにかく今とほとんど同じです：

// can throw SyntaxError
declare function a_fancy_3rd_party_lib_function(): MyType;

function fn1() {
    if (something) {
        throws "damn!";
    }

    if (something else) {
        throws new Error("oops");
    }

    a_fancy_3rd_party_lib_function();
}

function fn2() {
    try {
        fn1();
    } catch(e) {
        if (typeof e === "string") { ... }
        else if (e instanceof MyError) { ... }
    }
}

これからもtypescriptで保護することができますが、javascriptとは少し異なる構文が必要になります。

function fn2() {
    try {
        fn1();
    } catch(typeof e === "string") {
        ...
    } catch(e instanceof MyError) {
        ...
    }
}

これは次のようにコンパイルされます。

function fn2() {
    try {
        fn1();
    } catch(e) {
        if (typeof e === "string") {}
        else if (e instanceof MyError) {} 
        else {
            throw e;
        }
    }
}

おい！ 返信ありがとうございます！ 実際、あなたが言ったようにスローを推測することで、私が考えていたこの問題を軽減できます。 しかし、あなたがリストした2番目の例は興味深いものです。

与えられた

function first() : string throws MyVeryImportantError { // Compiler complains: missing number and string
    if(something) {
        throw MyVeryImportantError
    } else {
        return second().toString();
    }
}

function second() : number {
    if(something)
        throw 5;
    else   
        return third();
}

function third() : number throws string {
    if(!something)
        throw 'oh no!';
    return 9;
}

MyVeryImportantErrorを明示的に宣言するには、コールスタックのすべての追加エラーも明示的に宣言する必要があります。これは、アプリケーションの深さによっては一握りになる可能性があります。 また、面倒な可能性もあります。 途中で発生する可能性のある潜在的なエラーのリストを生成するために、コールチェーン全体を掘り下げたくないのは確かですが、おそらくIDEが役立つ可能性があります。

私は、開発者がエラーを明示的に宣言し、残りを捨てることができるように、ある種のスプレッド演算子を提案することを考えていました。

function first() : string throws MyVeryImportantError | ... { // Spread the rest of the errors

しかし、同じ結果を達成するためのより簡単な方法があります。スロー宣言を削除するだけです。

function first() : string { // Everything automatically inferred

どちらが問題を提起します：typescriptにエラーを推測させるのではなく、 throwsキーワードを使用することの利点はいつ見られるでしょうか？

@ConnorSinnott

これは、throw句を使用する他の言語、つまりjavaと同じです。
しかし、ほとんどの場合、実際には多くのタイプを扱う必要はないと思います。 現実の世界では、通常、 string 、 Error （およびサブクラス）とさまざまなオブジェクト（ {} ）のみを扱います。
そして、ほとんどの場合、複数のタイプをキャプチャする親クラスを使用することができます。

type MyBaseError = {
    message: string;
};

type CodedError = MyBaseError & {
    code: number;
}

function fn1() throws MyBaseError {
    if (something) {
        throw { message: "something went wrong" };
    }
}

function fn2() throw MyBaseError {
    if (something) {
        throw { code: 2, message: "something went wrong" };
    }

    fn1();
}

暗黙的にthrow句を使用する場合と、コンパイラに推測させる場合については、typescriptで型を宣言するのと同じだと思います。多くの場合、そうする必要はありませんが、コードをより適切に文書化するために行うことができます。後でそれを読む人は誰でもそれをよりよく理解することができます。

型の安全性が必要な場合の別のアプローチは、エラーをGolangの値として扱うことです。
https://gist.github.com/brandonkal/06c4a9c630369979c6038fa363ec6c83
それでも、これは便利な機能です。

@brandonkal
そのアプローチは、スレッドの前半ですでに説明されています。
可能ですが、そうすることは、javascriptで許可されている固有の部分/機能を無視することです。

また、 noexcept指定子（＃36075）は、現時点で最も単純で最良のソリューションだと思います。ほとんどのプログラマーと同様に、例外をスローするとアンチパターンが考慮されます。

ここにいくつかのクールな機能があります：

1. 関数を検証してもエラーは発生しません。

noexcept function foo(): void {
  throw new Error('Some exception'); // <- compile error!
}

1. 冗長なtry..catchブロックに関する警告：

try { // <- warning!
  foo();
} catch (e) {}

1. 常に約束を解決する：

interface ResolvedPromise<T> extends Promise<T> {
  // catch listener will never be called
  catch(onrejected?: noexcept (reason: never) => never): ResolvedPromise<T>; 

  // same apply for `.then` rejected listener,
  // resolve listener should be with `noexpect`
}

@moshest

ほとんどのプログラマーと同様に、例外をスローするとアンチパターンが考慮されます。

私はその「ほとんどのプログラマー」グループの一員ではないと思います。
noexceptはかっこいいですが、それはこの問題の目的ではありません。

ツールがあれば、それを使用します。 throw 、 try/catch 、 rejectがあるので、それらを使用します。

それらをtypescriptで適切に入力できると便利です。

ツールがあれば、それを使用します。 throw 、 try/catch 、 rejectがあるので、それらを使用します。

もちろん。 私も使います。 私のポイントは、 noexceptまたはthrows neverがこの問題の良いスタートになるということです。

ばかげた例： Math.sqrt(-2)を呼び出すと、エラーがスローされないことを知りたいです。

同じことがサードパーティライブラリにも当てはまります。 これにより、プログラマーとして処理する必要のあるコードとエッジケースをより細かく制御できます。

@moshest
しかし、なぜ？
この提案には、「予期しない」提案のすべての利点が含まれています。

時間がかかるので（この号は3年前です）、少なくとも最も基本的な機能から始められることを望んでいました。

@moshest
まあ、私はより短い時間で済む部分的な解決策よりも時間がかかるより良い機能を好みますが、私たちはそれを永遠に使い続けます。

noexceptは後で簡単に追加できるように感じますが、実際には別のトピックである可能性があります。

noexceptはthrows neverと同じです。

TBH try/catchの型のヒントを提供するよりも、例外の処理を保証するメカニズム（Goではerrorは使用されません）を用意する方が重要だと思います。

@rollは「保証」があってはなりません。
javascriptで例外を処理する必要はなく、typescriptでも必須ではありません。

typescryptの厳密モードの一部として、関数がエラーをキャッチするか、明示的にthrowsを宣言して渡す必要があるオプションである可能性があります。

5セントを追加すると、 nullを返す関数に似た例外が表示されます。これは、通常は発生しないと予想されることです。 しかし、それが発生した場合、実行時エラーが発生します。これは悪いことです。 現在、TSは、 nullの処理を思い出させるために、「null許容型ではない型」を追加しました。 throwsを追加すると、例外も処理するように通知することで、これらの取り組みをさらに一歩進めることができます。 だからこそ、この機能は絶対に必要だと思います。

エラーをスローする代わりに返すGoを見ると、両方の概念にそれほど違いがないことがさらに明確にわかります。 また、一部のAPIをより深く理解するのに役立ちます。 たぶん、いくつかの関数がスローできることを知らず、本番環境のかなり後の段階でそれに気付くでしょう（たとえば、 JSON.parse 、あといくつあるか知っている人はいますか？）。

@ obedm503これは実際にはTSの哲学です。デフォルトでは、コンパイラーは何も文句を言いません。 オプションを有効にして特定のものをエラーとして扱うか、厳密モードを有効にしてすべてのオプションを一度に有効にすることができます。 だから、これは与えられるべきです。

私はこの提案された機能が大好きです。
例外の入力と推論は、プログラミングの歴史全体で最も優れたものの1つです。
❤️

こんにちは、私はTSで現在行っている回避策を見つけるために少し時間を費やしました。 関数スコープ内でスローされたエラーの型を取得する方法がないため（また、現在のメソッドの型を取得する方法もありません）、メソッド自体に予期されるエラーを明示的に設定する方法を理解しました。 後で、それらの型を取得して、少なくともメソッド内で何がスローされるかを知ることができます。

これが私のPOCです

/***********************************************
 ** The part to hide a type within another type
 **********************************************/
// A symbol to hide the type without colliding with another existing type
const extraType = Symbol("A property only there to store types");

type extraType<T> = {
    [extraType]?: T;
}

// Set an extra type to any other type
type extraTyped<T, E> = T & extraType<E>

// Get back this extra type
type getExtraType<T> = T extends extraType<infer T> ? T : never;

/***********************************************
 ** The part to implement a throwable logic
 **********************************************/

// Throwable is only a type holding the possible errors which can be thrown
type throwable<T, E extends Error> = extraTyped<T,E>

// return the error typed according to the throwableMethod passed into parameter
type basicFunction = (...any: any[]) => any;
const getTypedError = function<T extends basicFunction> (error, throwableMethod:T) {
    return error as getExtraType<ReturnType<T>>;
};

/***********************************************
 ** An example of usage
 **********************************************/

class CustomError extends Error {

}

// Here is my unreliable method which can crash throwing Error or CustomError.
// The returned type is simply our custom type with what we expect as the first argument and the
// possible thrown errors types as the second (in our case a type union of Error and CustomError)
function unreliableNumberGenerator(): throwable<number, Error | CustomError> {

    if (Math.random() > 0.5) {
        return 42;
    }

    if (Math.random() > 0.5) {
        new Error('No luck');
    }

    throw new CustomError('Really no luck')
}

// Usage
try {
    let myNumber = unreliableNumberGenerator();
    myNumber + 23;
}

// We cannot type error (see TS1196)
catch (error) {
    // Therefore we redeclare a typed value here and we must tell the method which could have crashed
    const typedError = getTypedError(error, unreliableNumberGenerator);

    // 2 possible usages:
    // Using if - else clauses
    if (typedError instanceof CustomError) {

    }

    if (typedError instanceof Error) {

    }

    // Or using a switch case on the constructor:
    // Note: it would have been really cool if TS did understood the typedError.constructor is narrowed by the types Error | CustomError
    switch (typedError.constructor) {
        case Error: ;
        case CustomError: ;
    }

}

// For now it is half a solution as the switch case is not narrowing anything. This would have been 
// possible if the typedError would have been a string union however it would not be reliable to rely
// on typedError.constructor.name (considering I would have find a way to convert the type union to a string union)

あなたの正のフィードバックをどうもありがとう！ 返された型全体をthrowable型にラップしなくても、既存のコードをリファクタリングする方が簡単な場合があることに気付きました。 代わりに、返された型にその1つを追加するだけで済みます。次のコードを使用すると、スロー可能なエラーを次のように追加できます。

// now only append '& throwable<ErrorsThrown>' to the returned type
function unreliableNumberGenerator(): number & throwable<Error | CustomError> { /* code */ }

これは、サンプル部分の唯一の変更です。新しい型の宣言は次のとおりです。

/***********************************************
 ** The part to hide a type within another type
 **********************************************/
// A symbol to hide the type without colliding with another existing type
const extraType = Symbol("A property only there to store types");

type extraType<T> = {
    [extraType]?: T;
}

// Get back this extra type
type getExtraType<T> = T extends extraType<infer T> ? T : never;

/***********************************************
 ** The part to implement a throwable logic
 **********************************************/

// Throwable is only a type holding the possible errors which can be thrown
type throwable<E extends Error> = extraType<E>

// return the error typed according to the throwableMethod passed into parameter
type basicFunction = (...any: any[]) => any;

type exceptionsOf<T extends basicFunction> = getExtraType<ReturnType<T>>;

const getTypedError = function<T extends basicFunction> (error: unknown, throwableMethod:T) {
    return error as exceptionsOf<T>;
};

また、責任をエスカレートするために関数のエラーを抽出できる新しいタイプexceptionsOfを追加しました。 例えば：

function anotherUnreliableNumberGenerator(): number & throwable<exceptionsOf<typeof unreliableNumberGenerator>> {
// I don't want to use a try and catch block here
    return (Math.random() > 0.5) ? unreliableNumberGenerator() : 100;
}

exceptionsOfはエラーの結合を取得するため、必要な数の重要なメソッドをエスカレーションできます。

function aSuperUnreliableNumberGenerator(): number & throwable<exceptionsOf<typeof unreliableNumberGenerator> | exceptionsOf<typeof anotherUnreliableNumberGenerator>> {
// I don't want to use a try and catch block here
    return (Math.random() > 0.5) ? unreliableNumberGenerator() : unreliableNumberGenerator();
}

typeofの使用は好きではありません。もっと良い方法を見つけたら、お知らせします。

ここで結果のヒントをテストできます：行106でtypedErrorにカーソルを合わせます

@Xampleこれは、現在使用しているツールを使用した優れたソリューションです。
しかし、実際には、次のようなことができるので、それだけでは不十分だと思います。

const a = superRiskyMethod();
const b = a + 1;

そして、bのタイプは正しい数として推測されますが、それが試行の中に包まれている場合だけです
これは有効ではありません

@luisgurmendezMLabs私はあなたが何を意味するのかよくわかりません。 56行目の@Xampleのレポをたどると、 myNumber + 23 numberとして推測され、 myNumber: number & extraType<Error | CustomError>であることがわかります。

別のフェーズでは、例のaがTryMonadのようなものにラップされることはありません。 & extraType<Error | CustomError>との交差点以外にラッパーはありません。

素晴らしいデザイン@Xample👏👏👏👏👏👏おめでとうございます。 これは本当に有望であり、構文糖衣がなくてもすでに有用です。 このためのタイプライブラリを構築する計画はありますか？

@ivawzh私の考えでは、実際には、これによりいくつかの問題が発生する可能性があります。

function stillARiskyMethod() { 
    const a = superRiskyMethod();
    return a + 1
}

その関数型の戻り値は数値として推測され、それは完全には正しくありません

@luisgurmendezMLabsスロー可能な型は、エラーの型を関数に固定する（そして後でそれらの型を回復できるようにする）方法としてのみ、関数の戻り型内にあります。 私は実際にエラーを返すことは決してなく、それらを投げるだけです。 したがって、tryブロック内にいるかどうかは、何も変更されません。

@ivawzh質問してくれてありがとう、私はあなたのためにそれをやった

@luisgurmendezMLabsああ、わかりました。typescriptは、最初に見つかったタイプのみを推測しているようです。 たとえば、次の場合：

function stillARiskyMethod() { 
    return superRiskyMethod();
}

StillARiskyMethodの戻りタイプは正しく推測されますが、

function stillARiskyMethod() { 
    return Math.random() < 0.5 superRiskyMethod() : anotherSuperRiskyMethod();
}

戻り型をsuperRiskyMethod()としてのみ入力し、 anotherSuperRiskyMethod()の1つを閉じます。 私はこれ以上調査していません

このため、エラータイプを手動でエスカレーションする必要があります。

function stillARiskyMethod(): number & throwable<exceptionOf<typeof superRiskyMethod>> { 
    const a = superRiskyMethod();
    return a + 1
}

私もこれに自分の考えを落としたかっただけです。

Error / nullを返したい場合と何かをスローしたい場合にはさまざまなユースケースがあり、多くの可能性があるため、これは実装するのに非常に優れた機能だと思います。 とにかく例外をスローすることはJavascript言語の一部ですが、なぜこれらを入力して推測するオプションを与えてはいけないのでしょうか。

たとえば、エラーが発生する可能性のある多くのタスクを実行している場合、毎回returnタイプをチェックするためにifステートメントを使用する必要があるのは不便です。これは、try / catch whereifを使用することで簡略化できます。これらのタスクの1つがスローされ、追加のコードなしでキャッチで処理されます。

これは、エラーを同じ方法で処理する場合に特に便利です。 たとえば、express / node.jsでは、エラーをNextFunction （エラーハンドラー）に渡したい場合があります。

毎回if (result instanceof Error) { next(result); }を実行するのではなく、これらのタスクのすべてのコードをtry / catchでラップすることができます。私のキャッチでは、例外がスローされたので、これを常に自分のエラーハンドラなので、 catch(error) { next(error); }も可能です

また、これについてはまだ説明されていません（ただし、見逃している可能性がありますが、このスレッドにはかなりの数のコメントがあります！）が、これが実装されている場合、を使用せずにスローする関数を持つことが必須になります（つまり、コンパイルエラー）。関数宣言のthrows句？ これはいいことだと思います（スローを処理するように強制するのではなく、関数がスローすることを通知するだけです）が、ここでの大きな懸念は、Typescriptがこのように更新された場合、現在存在する多くのコードを壊します。

編集：私が考えたもう1つのユースケースは、@ throwsタグを使用したJSDocの生成にも役立つ可能性があります

ここで、今コミットされている問題で私が言ったことを繰り返します。

typescriptは、ほとんどのJavaScript式のエラータイプを推測できるはずだと思います。 ライブラリ作成者によるより迅速な実装を可能にします。

function a() {
  if (Math.random() > .5) {
    throw 'unlucky';
  }
}

function b() {
  a();
}

function c() {
  if (Math.random() > .5) {
    throw 'unlucky';
  }
  if (Math.random() > .5) {
    throw 'fairly lucky';
  }
}

function d() {
  return eval('You have no IDEA what I am capable of!');
}

function e() {
  try {
    return c;
  } catch(e) {
    throw 'too bad...';
  }
}

function f() {
  c();
}

function g() {
  a();
  c();
}

• 関数aは、エラータイプが'unlucky'であることを知っています。非常に注意したい場合は、 Error | 'unlucky'に拡張できます。したがって、 includeErrorに拡張できます。
• 関数bは、関数aのエラータイプを継承します。
• 関数cはほとんど同じです。 'unlucky' | 'fairly lucky' 、またはError | 'unlucky' | 'fairly lucky' 。
• 関数dは、evalが...不明であるため、 unknownをスローする必要があります
• 関数eはdのエラーをキャッチしますが、catchブロックにはthrowがあるため、ここでは、ブロックのみであるため、そのタイプ'too bad...'を推測します。 throw 'primitive value'が含まれています$＃ Errorをスローできないと言えます（JSの黒魔術を逃した場合は訂正してください...）
• 関数fは、 bがaから行ったのと同じように、 cから継承します。
• 関数g $はa 'unlucky' $を継承し、 c unknown $を継承するため、 'unlucky' | unknown => unknown

この機能を使用するユーザーは、特定のプロジェクトで依存しているライブラリのスキルやタイプの安全性によって異なる可能性があるため、含める必要があると思われるコンパイラオプションを次に示します。

{
  "compilerOptions": {
    "errorHandelig": {
      "enable": true,
      "forceCatching": false,   // Maybe better suited for TSLint/ESLint...
      "includeError": true, // If true, every function will by default throw `Error | (types of throw expressions)`
      "catchUnknownOnly": false, // If true, every function will by default throw `unknown`, for those very skeptics (If someone replaces some global with weird proxy, for example...)
      "errorAsesertion": true,  // If false, the user will not be able to change error type manually
    }
  }
}

関数が生成する可能性のあるエラーを表現する方法の構文についてはわかりませんが、一般的で推論可能な関数が必要であることはわかっています。

declare function getValue<T extends {}, K extends keyof T>(obj: T, key: K): T[K] throws void;
declare function readFile<throws E = 'not valid file'>(file: string, customError: E): string throws E;

私のユースケースは、実際のユースケースを示すと、他のユースケースを示す可能性があるため、次のような値があります。

declare function query<T extends {}, throws E>(sql: string, error: E): T[] throws E;

app.get('path',(req, res) => {
  let user: User;
  try {
    user = query('SELECT * FROM ...', 'get user');
  } catch(e) {
    return res.status(401);
  }

  try {
    const [posts, followers] = Promise.all([
      query('SELECT * FROM ...', "user's posts"),
      query('SELECT * FROM ...', "user's follower"'),
    ]);

    res.send({ posts, followers });
  } catch(e) {
    switch (e) {
      case "user's posts":
        return res.status(500).send('Loading of user posts failed');

      case "user's posts":
        return res.status(500).send('Loading of user stalkers failed, thankfully...');

      default:
        return res.status(500).send('Very strange error!');
    }
  }
});

複数のエラーに対して応答のヘッダーが複数回送信されるのを防ぐために、エラーシンクが必要です（通常は発生しませんが、大量に送信する場合は発生します）。

この問題にはまだAwaiting More Feedbackのタグが付いていますが、フィードバックをさらに提供するにはどうすればよいですか？ これは私がJava言語をうらやましく思う唯一の機能です

API呼び出しが200以外のコードを返すときに、特定のエラーをスローするユースケースがあります。

interface HttpError extends Error {
  response: Response
}

try {
  loadData()
} catch (error: Error | ResponseError) {
  if (error.response) {
    checkStatusCodeAndDoSomethingElse()
  } else {
    doGenericErrorHandling()
  }
}

catchブロックを入力できないと、開発者は2種類のエラーがスローされる可能性があることを忘れてしまい、両方を処理する必要があります。

私は常にErrorオブジェクトをスローすることを好みます：

function fn(num: number): void {
    if (num === 0) {
        throw new TypeError("Can't deal with 0")
    }
}
try {
 fn(0)
}
catch (err) {
  if (err instanceof TypeError) {
   if (err.message.includes('with 0')) { .....}
  }
}

この機能がまだ「十分なフィードバックがない」のはなぜですか？ indexedDB、localstorageなどのブラウザのAPIを呼び出すときに非常に便利です。 それは複雑なシナリオで多くの失敗を引き起こしましたが、開発者はプログラミングで気付くことはできません。

ヘーゲルはこの機能を完全に備えているようです。
https://hegel.js.org/docs#benefits （「入力されたエラー」セクションまでスクロール）

TypeScriptにも同様の機能があればいいのにと思います。

DL; DR;

• promiseの拒否関数を入力する必要があります
• tryブロック内でスローされたタイプはすべて、ユニオンを使用してcatchのエラー引数に推論する必要があります。
• error.constructorは、スローされたエラーを見逃さないように、 anyだけでなく、実際の型を使用して適切に型指定する必要があります。

さて、おそらく私たちは私たちのニーズと期待が何であるかを単純に明確にする必要があります：

エラーは通常、jsでは3つの方法で処理されます

1.ノードウェイ

コールバックの使用（実際に入力できます）

使用例：

import * as fs from 'fs';

fs.readFile('readme.txt', 'utf8',(error, data) => {
    if (error){
        console.error(error);
    }
    if (data){
        console.log(data)
    }
});

fs.d.tsが私たちに与えるところ：

function readFile(path: PathLike | number, options: { encoding: string; flag?: string; } | string, callback: (err: NodeJS.ErrnoException | null, data: string) => void): void;

したがって、エラーは次のように入力されます

    interface ErrnoException extends Error {
        errno?: number;
        code?: string;
        path?: string;
        syscall?: string;
        stack?: string;
    }

2.約束の方法

約束が解決または拒否される場合、解決されたvalueを入力することはできますが、 reasonと呼ばれることが多い拒否を入力することはできません。

これがpromiseのコンストラクターの署名です。理由はanyと入力されていることに注意してください。

    new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

理論的には、次のように入力することが可能でした。

    new <T, U=any>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: U) => void) => void): Promise<T>;

このようにして、理論的には、ノードコールバックとpromiseの間で1対1の変換を行い、このプロセスに沿ってすべての入力を維持することができます。 例えば：

const fs = require('fs')
const util = require('util')

const readFilePromise = util.promisify(fs.readFile); // (path: PathLike | number, options: { encoding: string; flag?: string; } | string) => Promise<data: string, NodeJS.ErrnoException>;

3.「試してキャッチ」の方法

try {
    throw new Error();
}
catch (error: unknown) { //typing the error is possible since ts 4.0
    if (error instanceof Error) {
        error.message;
    }
}

キャッチブロックの2行前にエラー「エラー」をスローしていますが、TSはerror （値）をError （タイプ）として入力できません。

async関数内でpromiseを使用することもありません（「まだ」魔法はありません）。 約束されたノードコールバックの使用：

async function Example() {
    try {
        const data: string = await readFilePromise('readme.txt', 'utf-8');
        console.log(data)
    }
    catch (error) { // it can only be NodeJS.ErrnoException, we can type is ourself… but nothing prevents us to make a mistake
        console.error(error.message);
    }
}

tryスコープ内でスローされる可能性のあるエラーのタイプを予測できるようにするためのtypescriptの欠落情報はありません。
ただし、内部のネイティブ関数がソースコード内にないエラーを発生させる可能性があることを考慮する必要がありますが、「throw」キーワードがソースにあるたびに、TSはタイプを収集し、エラーの可能性のあるタイプとして提案する必要があります。 もちろん、これらのタイプはtryブロックによってスコープされます。

これは最初のステップに過ぎず、厳密なモードでTSをJavaのように動作させる、つまりユーザーにtry以内で危険なメソッド（何かをスローできるメソッド）を使用させるなど、まだ改善の余地があります。 function example throw ErrorType { ... }として明示的にマークして、エラー処理の責任をエスカレートします。

最後になりましたが、エラーを見逃さないようにしてください

エラーやオブジェクトのインスタンスだけでなく、何でもスローできます。 以下が有効であることを意味します

try {
    if (Math.random() > 0.5) {
        throw 0
    } else {
        throw new Error()
    }
}
catch (error) { // error can be a number or an object of type Error
    if (typeof error === "number") {
        alert("silly number")
    }

    if (error instanceof Error) {
        alert("error")
    }
}

エラーがnumber | Errorタイプである可能性があることを知ることは、非常に役立ちます。 ただし、考えられるタイプのエラーの処理を忘れないようにするために、考えられる結果の厳密なセットなしで、個別のif / elseブロックを使用することは実際には最善のアイデアではありません。
ただし、特定のケース（デフォルトの句にフォールバックするケース）に一致するのを忘れた場合に警告が表示される可能性があるため、switchケースの方がはるかに優れています。 オブジェクトインスタンスタイプのケースを切り替えることはできません（何かハックなことをしない限り）。できたとしても、何でもスローできます（オブジェクトだけでなく、ブール値、文字列、および「インスタンス」のない数値）。 ただし、インスタンスのコンストラクターを使用して、インスタンスがどのタイプであるかを確認できます。 これで、上記のコードを次のように書き直すことができます。

try {
    if (Math.random() > 0.5) {
        throw 0
    } else {
        throw new Error()
    }
}
catch (error) { // error can be a Number or an object of type `Error`
    switch (error.constructor){
        case Number: alert("silly number"); break;
        case Error: alert("error"); break;
    }
}

Horray…残っている唯一の問題は、TSがerror.constructorを入力しないため、スイッチケースを絞り込む方法がないことです（まだ？）。そうする場合、安全に入力されたエラー言語があります。 js。

さらにフィードバックが必要な場合はコメントしてください