例外をキャッチ/スローすると、純粋なメソッドが不純になりますか？

次のコード例は、私の質問の背景を示しています。

Roomクラスはデリゲートで初期化されます。Roomクラスの最初の実装では、例外をスローするデリゲートに対するガードはありません。このような例外は、デリゲートが評価されるNorthプロパティにバブルアップします（注：Main（）メソッドは、クライアントコードでRoomインスタンスがどのように使用されるかを示します）。

public sealed class Room
{
    private readonly Func<Room> north;

    public Room(Func<Room> north)
    {
        this.north = north;
    }

    public Room North
    {
        get
        {
            return this.north();
        }
    }

    public static void Main(string[] args)
    {
        Func<Room> evilDelegate = () => { throw new Exception(); };

        var kitchen = new Room(north: evilDelegate);

        var room = kitchen.North; //<----this will throw

    }
}

Northプロパティを読み取るときではなく、オブジェクトの作成時に失敗するので、コンストラクターをprivateに変更し、Create（）という名前の静的ファクトリーメソッドを導入します。このメソッドは、デリゲートによってスローされた例外をキャッチし、意味のある例外メッセージを持つラッパー例外をスローします。

public sealed class Room
{
    private readonly Func<Room> north;

    private Room(Func<Room> north)
    {
        this.north = north;
    }

    public Room North
    {
        get
        {
            return this.north();
        }
    }

    public static Room Create(Func<Room> north)
    {
        try
        {
            north?.Invoke();
        }
        catch (Exception e)
        {
            throw new Exception(
              message: "Initialized with an evil delegate!", innerException: e);
        }

        return new Room(north);
    }

    public static void Main(string[] args)
    {
        Func<Room> evilDelegate = () => { throw new Exception(); };

        var kitchen = Room.Create(north: evilDelegate); //<----this will throw

        var room = kitchen.North;
    }
}

try-catchブロックはCreate（）メソッドを不純にしますか？

はい。 これは事実上不純な機能です。副作用が発生します。プログラムの実行は、関数が戻ると予想される場所以外の場所で継続します。

それを純粋な関数にするために、関数returnから期待される値と、Maybeオブジェクトや作業単位オブジェクトのような可能性のあるエラー状態を示す値をカプセル化する実際のオブジェクト。

まあ、はい...そしていいえ。

純粋な関数には参照の透明性が必要です。つまり、プログラムの動作を変更することなく、純粋な関数の呼び出しを戻り値に置き換えることができるはずです。^*関数は特定の引数に対して常にスローすることが保証されているため、関数呼び出しを置き換える戻り値はないため、代わりに無視します。次のコードを検討してください。

{
    var ignoreThis = func(arg);
}

場合はfunc純粋で、オプティマイザはそれを決めることができましたfunc(arg)それをその結果で置き換えるができるとできます。結果が何であるかはまだわかりませんが、使用されていないことがわかります。そのため、このステートメントを推測するだけで効果はなく、削除できます。

しかし、もしfunc(arg)スローが起こると、このステートメントは何かをします-例外をスローします！そのため、オプティマイザはそれを削除できません-関数が呼び出されるかどうかは問題になりません。

しかし...

実際には、これはほとんど問題になりません。例外-少なくともC＃では-は例外的なものです。通常の制御フローの一部として使用することは想定されていません。それを試行してキャッチする必要があります。何かをキャッチした場合、エラーを処理して、実行中の操作を元に戻すか、何らかの方法でそれを達成します。失敗するコードが最適化されて削除されたためにプログラムが正常に動作しない場合は、間違った例外を使用しています（テストコードではなく、テスト用にビルドする場合は例外を最適化しないでください）

言われていること...

キャッチされることを意図して純粋な関数から例外をスローしないでください-関数型言語がスタックアンワインド例外の代わりにモナドを使用することを好む十分な理由があります。

C＃にErrorJava（および他の多くの言語）のようなクラスがある場合、のError代わりにをスローすることをお勧めしExceptionます。これは、関数のユーザーが何か間違ったことをした（スローする関数を渡した）ことを示し、そのようなことは純粋な関数で許可されています。しかし、C＃にはErrorクラスがなく、使用法エラーの例外はから派生しているようですException。私の提案は、をスローするArgumentExceptionことで、関数が間違った引数で呼び出されたことを明確にします。

^* _{計算的に言えば。素朴な再帰を使用して実装されたフィボナッチ関数は、多数の場合に時間がかかり、マシンのリソースを使い果たす可能性がありますが、無限の時間とメモリがあるため、関数は常に同じ値を返し、副作用はありません（割り当て以外は）メモリとそのメモリの変更）-それはまだ純粋と見なされます。}

1つの考慮事項は、try-catchブロックが問題ではないことです。（上記の質問に対する私のコメントに基づく）。

主な問題は、NorthプロパティがI / O呼び出しであることです。

コードの実行のその時点で、プログラムはクライアントコードによって提供されるI / Oを確認する必要があります。（入力がデリゲートの形式であることや、名目上、入力が既に渡されていることは関係ありません）。

入力の制御を失うと、関数が純粋であることを保証できません。（特に関数がスローできる場合）。

Move [Check] Roomの呼び出しを確認したくない理由がわかりません。質問への私のコメントに従って：

はい。デリゲートを実行すると、最初にしか機能しない、または2回目の呼び出しで別の部屋に戻る場合はどうしますか デリゲートを呼び出すことは考慮されることができます/副作用自体を引き起こしますか？

バート・ファン・インゲン・シェナウが上で言ったように、

Create関数は、プロパティを取得するときに例外が発生するのを防ぎません。デリゲートがスローされる場合、実際には、特定の条件下でのみスローされる可能性が非常に高くなります。投げる条件は建設中に存在しない可能性がありますが、プロパティを取得するときに存在します。

一般に、どのタイプの遅延読み込み でも、その時点まで暗黙的にエラーが延期されます。

Move [Check] Roomメソッドを使用することをお勧めします。これにより、不純なI / Oアスペクトを1つの場所に分離できます。

ロバート・ハーベイの答えに似ています：

それを純粋な関数にするには、関数からの期待値をカプセル化する実際のオブジェクトと、可能性のあるエラー状態を示す値（Maybeオブジェクトや作業単位オブジェクトなど）を返します。

入力から（可能性のある）例外を処理する方法を決定するのはコードライター次第です。その後、このメソッドはRoomオブジェクトまたはNull Roomオブジェクトを返すか、例外をバブルアウトすることができます。

この点は次の点に依存します。

• ルームドメインは、ルーム例外をNullまたはその他の問題として扱いますか？
• Null / Exception RoomでNorthを呼び出すクライアントコードに通知する方法。（保釈/ステータス変数/グローバル状態/モナドを返す/何でも;あるものは他のものより純粋です:)）。

うーん...私はこれについて正しくないと感じました。あなたがやろうとしていることは、他の人が何をしているのかを知らずに、自分の仕事を正しく行うようにすることだと思います。

関数はコンシューマーによって渡されるため、ユーザーまたは他の人が作成できます。

Roomオブジェクトが作成されたときに、関数パスインの実行が有効でない場合はどうなりますか？

コードから、私は北朝鮮が何をしているかを確信できませんでした。

機能が部屋の予約であり、予約の時間と期間が必要な場合、情報の準備ができていない場合は例外が発生します。

長時間実行される機能の場合はどうなりますか？Roomオブジェクトの作成中にプログラムをブロックしたくない場合、1000 Roomオブジェクトを作成する必要がある場合はどうなりますか？

あなたがこのクラスを使用するコンシューマを作成する人であれば、渡された関数が正しく作成されていることを確認しませんか？

消費者を書く他の人がいる場合、彼/彼女は部屋オブジェクトを作成する「特別な」条件を知らないかもしれません。

もう1つは、新しい例外をスローすることは必ずしも良いことではありません。理由は、元の例外の情報が含まれないことです。エラーが発生することはわかっていますが（一般的な例外のわかりやすい手段）、エラーの内容（null参照、範囲外のインデックス、ゼロ除算など）はわかりません。この情報は、調査を行う必要がある場合に非常に重要です。

例外の処理方法を知っている場合にのみ、例外を処理する必要があります。

元のコードは十分だと思います。唯一のことは、「メイン」（またはその処理方法を知っている任意のレイヤー）で例外を処理することです。

他の答えには賛成せず、いいえと言います。例外が原因で純粋な関数が不純になることはありません。

例外の使用は、エラー結果の明示的なチェックを使用するように書き直すことができます。例外は、これに加えて構文上の砂糖と見なすことができます。便利な構文糖は純粋なコードを不純にしません。