Try/Catch를 랩핑하는 액션을 취하는 메시지 클래스 정적 메서드 사용하기

Question

이벤트 메시지 목록을 전달할 수있는 Result 개체가 있으며 작업의 성공 여부를 확인할 수 있습니다.

나는 곳을 많이에서이 코드를 작성했습니다 깨달았다

Result result; 

try 
{ 
    //Do Something 
    ... 

    //New result is automatically a success for not having any errors in it 
    result = new Result(); 
} 
catch (Exception exception) 
{ 
    //Extension method that returns a Result from the exception 
    result = exception.ToResult(); 
} 

if(result.Success) .... 

내가

처럼 사용 후

public static Result CatchException(Action action) 
{ 
    try 
    { 
     action(); 
     return new Result(); 
    } 
    catch (Exception exception) 
    { 
     return exception.ToResult(); 
    } 
} 

와 함께이 사용을 대체하고 고려 중이 야

var result = Result.CatchException(() => _model.Save(something)); 

누구나이 점이 잘못되었거나 내가 모호함을 재사용 할 수 있다고 생각합니까?

편집 : 나는 모든 예외를 트래핑하고 그 이유는 내가 처리되지 않은 예외가 있다면 오히려에 실제 오류를 표시 할 것 때문에 내가 나의 모델과 상호 작용 언제든지 내 ViewPresenter 클래스의 내부에이 코드를 사용하다 사용자 (내부 앱)가 일반 오류 페이지로 리디렉션하는 것과 대조적으로

Answer 1

기능적 접근 방식을 사용하고 람다를 전달하는 데 문제가 있다고 생각하지 않습니다. 그것은 완벽하게 유효합니다.

즉,이 특정 시나리오에서 사용하는 것이 좋습니다. 모든 예외를 범용 "결과"클래스에 트래핑하는 것은 위험한 것처럼 보입니다. 이상적으로는 가능한 모든 예외가 아닌 계속 처리 할 수있는 예외를 잡아야합니다. 당신이 정말로 이렇게 할 경우

말했다되는 것을, 나는 당신을 위해 몇 가지 제안이 있습니다

1) 내가 성공을위한 정적, 불변의 결과를 만들어 주겠다고를 그냥 수행

result = result.Success; 

이렇게하면 성공할 때마다 새로운 "성공"이 생성되지 않으므로 가장 일반적인 옵션이되기를 바랍니다.

2) 아마 확장 메서드를 방지하고, 할 거라고 :

result = new Result(exception); 

이 의도에서 훨씬 더 분명하고 명백 할 것이다,이 경우 확장 방법을 할 이유가 정말 없습니다. ..

Answer 2

이렇게하면 Exception을 잡지 말아야합니다. 처리 방법을 알고있는 알려진 예외 유형 만 잡아야합니다.

이렇게하면 코드가 더 이상 반복적이지 않으므로이 패턴을 재사용 가능성에 사용하지 않아도됩니다.

이 모든 라운드는 람다 패턴뿐만 아니라 매우 나쁜 생각처럼 보입니다. 예외 처리를 결과 개체로 변환하여 처리하는 것에 대해 이야기하고 있습니다. 기본적으로 모든 예외를 무시하고 계속 작업 할 수 있습니다. C# 오류 처리가 반환 코드가 아닌 예외를 사용하여 수행되는 이유는 예외가 구조적, 계층 적 및 호출 스택 기반 처리를 허용하기 때문입니다. 이 질문에 대한 코드를 단순화하지 않는 한 예외 처리 프로세스를 다시 생각해 보겠습니다.일반적으로

---

하지만, 나는 람다 패턴 아무 잘못 표시되지 않습니다. 나는 코드 블럭의 여러 재 시도를 래핑하기 위해 비슷한 것을 사용한다. 그러나이 경우 나는 그것이 당신이 필요로하는 것이라고 생각하지 않습니다.

Answer 3

이러한 자동화 된 예외 처리기 시스템을 작성해야 할 필요성이 느껴지면 예외가 지나치게 많이 사용되어 성능에 심각한 영향을 미칠 수 있습니다.

그러나 이것은 예외를 오류 코드로 변환하는 일반적인 시스템 인 것으로 보이므로 처음에는 오류 코드를 사용하지 않는 것이 좋습니다. 또는 예외를보다 효과적으로 사용하여 오류 코드로 변환 할 필요가 없다고 생각하십니까? 당신이 뭔가 다른 것으로 그들을 변환하려고한다는 사실은 경보를 제기하고 어딘가에 요점을 놓치고 있다고 제안해야합니다.