例外
==========================================================================================

一部の型チェック動作（型の絞り込みや到達可能性の分析など）では、型チェッカーがコードフローを理解する必要があります。 コードフローは通常、ある文から次の文へと進行しますが、``for``、``while``、``return`` などの一部の文はコードフローを変更することがあります。 同様に、``try``/``except``/``finally`` 文はコードフローに影響を与えるため、型評価にも影響を与える可能性があります。 例::

    x = None
    try:
        some_function()
        x = 1
    except NotImplementedError:
        pass

    # この時点での `x` の型は、`some_function` が例外を発生させた場合は None であり、発生させなかった場合は `Literal[1]` である可能性があるため、型チェッカーはこの分析に基づいてその型を絞り込むことを選択する場合があります。
    reveal_type(x)  # Literal[1] | None


コンテキストマネージャー
------------------------------------------------------------------------------------------

コンテキストマネージャーは、``__exit__`` メソッドから ``True``（または他の真値）を返すことで、例外を「抑制」することができます。 このようなコンテキストマネージャーが使用される場合、``with`` ブロック内で発生し、他にキャッチされない例外はコンテキストマネージャーによってキャッチされ、制御は ``with`` ブロックの直後に続きます。 コンテキストマネージャーが例外を抑制しない場合（通常はそうです）、``with`` ブロック内で発生し、他にキャッチされない例外は ``with`` ブロックを超えて伝播します。

コードフロー分析を行う型チェッカーは、これらの 2 つのケースを区別できる必要があります。 これは、コンテキストマネージャーの ``__exit__`` メソッドの戻り型注釈を調べることで行われます。

``__exit__`` メソッドの戻り型が特に ``bool`` または ``Literal[True]`` である場合、型チェッカーは例外が抑制される*可能性がある*と仮定する必要があります。 他の戻り型の場合、型チェッカーは例外が抑制され*ない*と仮定する必要があります。 例としては、``Any``、``Literal[False]``、``None``、および ``bool | None`` があります。

この慣習は、ほとんどのコンテキストマネージャーが例外を抑制しないため選ばれました。 そして、彼らの ``__exit__`` メソッドは ``bool | None`` を返すように注釈されることが一般的です。 例外を抑制するコンテキストマネージャーは比較的まれであり、特別なケースと見なされます。

たとえば、次のコンテキストマネージャーは例外を抑制します::

    class Suppress:
        def __enter__(self) -> None:
            pass

        def __exit__(self, exc_type, exc_value, traceback) -> bool:
            return True

    with Suppress():
        raise ValueError("この例外は抑制されます")

    # 例外が抑制されるため、この行は到達可能です。
    print("コードは到達可能です")