예외를 catch / throw하면 순수한 방법이 불완전합니까?

다음 코드 예제는 내 질문에 대한 컨텍스트를 제공합니다.

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함수가 잘못된 인수로 호출되었음을 분명히하는 것입니다.

^* _{계산적으로 말하기. 순진 재귀를 사용하여 구현 된 피보나치 함수는 많은 수의 시간이 오래 걸리고 머신의 리소스를 소모 할 수 있지만, 시간과 메모리가 무한하므로 함수는 항상 동일한 값을 반환하고 부작용 (할당 제외)이 없습니다 메모리와 메모리 변경)-여전히 순수한 것으로 간주됩니다.}

한 가지 고려 사항은 try-catch 블록이 문제가 아니라는 것입니다. (위의 질문에 대한 나의 의견을 바탕으로).

주요 문제는 North 속성이 I / O 호출이라는 것 입니다.

코드 실행 시점에서 프로그램은 클라이언트 코드에서 제공하는 I / O를 확인해야합니다. (입력이 위임의 형태이거나 입력이 명목상 이미 전달 된 것은 관련이 없습니다).

입력 제어를 잃으면 기능이 순수하다는 것을 보장 할 수 없습니다. (특히 함수가 던질 수있는 경우).

왜 Move [Check] Room 통화를 확인하고 싶지 않은지 잘 모르겠습니다. 질문에 대한 나의 의견에 따라 :

예. 대리인을 실행할 때 처음으로 만 작업하거나 두 번째 통화에서 다른 회의실을 반환 할 수 있습니까? 대리인에게 전화를 걸면 부작용 자체로 간주 / 발생할 수 있습니까?

Bart van Ingen Schenau가 위에서 말했듯이

Create 함수는 속성을 가져올 때 예외가 발생하지 않도록 보호하지 않습니다. 대리인이 실제 상황에서 던지면 일부 상황에서만 던질 가능성이 큽니다. 건설 중에는 던지기 조건이 없지만 재산을 얻을 때 존재하는 경우가 있습니다.

일반적으로 지연로드 의 모든 유형은 해당 시점까지 오류를 내재적으로 지연 시킵니다.

Move [Check] Room 메서드를 사용하는 것이 좋습니다. 이를 통해 불완전한 I / O 측면을 한 곳으로 분리 할 수 ​​있습니다.

Robert Harvey의 답변과 유사합니다 .

순수한 함수로 만들려면 함수에서 예상 값을 캡슐화하는 실제 오브젝트와 가능한 오브젝트 또는 작업 단위 오브젝트와 같은 가능한 오류 조건을 나타내는 값을 리턴하십시오.

입력에서 (가능한) 예외를 처리하는 방법을 결정하는 것은 코드 작성기에 달려 있습니다. 그런 다음이 메소드는 Room 객체 또는 Null Room 객체를 반환하거나 예외를 버블 링 할 수 있습니다.

이 시점은 다음에 달려 있습니다.

• Room 도메인은 Room Exception을 Null 또는 Something Worse로 취급합니까?
• Null / Exception Room에서 North를 호출하는 클라이언트 코드에 알리는 방법. (보석 / 상태 변수 / 전역 상태 / 모나드 반환 / 무엇이든; 일부는 다른 것보다 더 순수합니다 :)).

흠 ... 나는 이것에 대해 기분이 좋지 않았다. 나는 당신이하려는 일이 다른 사람들이 자신이하는 일을 알지 못하고 자신의 일을 올바르게 수행하도록하는 것이라고 생각합니다.

이 기능은 소비자가 전달하기 때문에 사용자 나 다른 사람이 작성할 수 있습니다.

Room 객체가 생성 될 때 함수 전달이 실행되지 않으면 어떻게됩니까?

코드에서, 나는 북한이 무엇을하고 있는지 확신 할 수 없었다.

기능이 방을 예약하는 것이며 예약 시간과 기간이 필요한 경우 정보가 준비되지 않은 경우 예외가 발생합니다.

장기 실행 기능인 경우 어떻게합니까? Room 객체를 만드는 동안 프로그램을 차단하고 싶지 않습니다. 1000 Room 객체를 만들어야하는 경우

이 클래스를 소비하는 소비자를 쓰는 사람이라면 전달 된 함수가 올바르게 작성되었는지 확인하십시오.

소비자를 작성하는 다른 사람이있는 경우, 룸 객체를 생성하는 "특별한"조건을 알지 못할 수 있으며, 이로 인해 예외가 발생할 수 있으며 원인을 찾으려고 머리를 긁을 수 있습니다.

또 다른 것은 항상 새로운 예외를 던지는 것이 좋은 것은 아닙니다. 그 이유는 원래 예외 정보를 포함하지 않기 때문입니다. 오류가 발생한다는 것을 알고 있지만 (일반 예외의 경우 친숙한 메시지), 오류가 무엇인지 알 수 없습니다 (널 참조, 범위를 벗어난 인덱스, 0으로 편차 등). 이 정보는 조사가 필요할 때 매우 중요합니다.

처리 방법과 처리 방법을 알고있는 경우에만 예외를 처리해야합니다.

원래 코드가 충분하다고 생각합니다. 유일한 것은 "메인"(또는 처리 방법을 알고있는 레이어)에서 예외를 처리하고 싶을 것입니다.

나는 다른 답변에 동의하고 말할 것이다 아니오 . 예외로 인해 순수한 기능이 불완전하게되는 것은 아닙니다.

오류 결과에 대한 명시 적 검사를 사용하기 위해 예외 사용을 다시 작성할 수 있습니다. 예외는 이것 외에도 구문 설탕으로 간주 될 수 있습니다. 편리한 구문 설탕은 순수한 코드를 불순하게하지 않습니다.