2012-08-10 2 views
4

나는 내 친구와 의견이 분분하다.세터에서 검증 : 어떤 접근 방식이 더 좋습니까?

method SetBalance(balance) { 
    if (balance < 0) { 
     throw new InvalidArgumentException("Balance couldn't be negative") 
    } 
    this.balance = balance; 
} 

내 질문은 : : "확인을위한 더 나은 어떤 방법"

method SetBalance(balance) { 
    if (balance > 0) { 
     this.balance = balance; 
     return true; 
    } 
    return false; 
} 

이 더 나은 다음 :

그는이 코드는 내게 말했다 그리고 왜?

감사합니다.

+0

균형을 조정할 수없는 이유는 무엇입니까? – Eimantas

+0

반환이 더 좋았더라도, 나는 bool보다는 더 기술적 인 것을 사용할 것입니다. – Giedrius

+0

예를 들어, Eimantas. –

답변

6

아. 반환 상태 대 예외.

나는 예외를 무시할 수 없기 때문에 예외를 던지는 것을 선호합니다. 프로그램이 충돌하거나 명시 적으로 catch하고 처리해야합니다.

반환 상태를 무시할 수 있습니다.

게다가 현대 프로그래밍에서 예외가 존재하지 않는 이유는 무엇입니까? 처리를 위해서, 잘 ... 예외 (잔액 < = 0, 일어나지 말아야 할 것).

+0

나는 예외를 피하기 위해 비용이 많이 든다는 주장이 있었다. 예외를 피할 수 있다면 다른 것을 사용하는 것이 좋겠지 만 오늘은 그렇지 않다. – Giedrius

+0

@Giedrus 아주 잘 알려진 만트라입니다. 여기에서 저자는 코딩 버그 수정에 대해 질문했습니다. 예외는 완벽 함을 의미합니다. –

+0

흠, 검증 및 유효성 검증은 대개 코드 로직이 아닌 입력 데이터의 유효성 확인을위한 것이라고 말했습니다. – Giedrius

1

세터의 경우 개발자는 값의 설정을 처리 할 것이라고 생각하기 때문에 이러한 메소드의 반환 값을 기대하지 않습니다.
예외가있는 경우, 이것은 뭔가 잘못되었다는 것을 이해하고 코드를 다시 살펴 보는 데 도움이됩니다.
runtime exception 대신 InvalidBalanceException과 같은 예외를 정의하고이 메서드가 서명 자체에이 예외를 throw하도록 지정하는 것이 좋습니다. 이를 통해 테스트 단계에서의 놀라움을 피하고 개발 단계에서 비즈니스 로직을 결정할 수 있습니다.

1

반환 값은 쉽게 무시됩니다. 여기서 명확한 코딩 버그가 있으므로 큰 소리로 충돌합니다. 심지어 멈추었을/segfault/중지 프로그램 - 예외는 여전히 잡힐 수 있습니다. 우리는 "이상적인 세상"에 살지만 불행한 동료를 상상해보십시오. 그들은 근본적인 원인을 다루지 못하는 허위 정보 전달 시설을 위해 잘 갈 것입니다. 코딩을하면 클라이언트가 잘못된 방식으로 일할 수있는 방법을 제공하지 않을 때 훨씬 쉽게됩니다.

0

이미 주어진 답변 외에 "setFoo"라는 함수에서 부울 값을 반환하는 것은 매우 잘못된 것입니다. 부울 값을 변환하는 경우 예/아니오로 나타납니다. 그래서 oop에 boolean을 반환하는 함수는 yes/no를 답으로 제공하는 질문으로 읽을 수 있어야합니다. isBalanceSet.

collegues와의 논의에서 일반적인 설정자에 대한 유일한 유효한 반환 값은 유창한 인터페이스의 클래스 자체입니다. 귀하의 질문에 던지는 예외에 관한

클래스가 실제로 속성 자체의 유효성을 검사하는 경우 더 나은 솔루션)

0

내 개인적인 의견 : 두 가지 접근 방식은 그 용도가있다. 상황이 왜 발생했는지, 예방할 수 있는지, 클라이언트가이를 방지하기 위해 할 수있는 일에 달려 있습니다.

서버 :

method SetBalance(int balance) 
{ 
    // do something only if balance >= 0 
} 

클라이언트 :

myServer.SetBalance(balance); 

사례 1 : 상황은 (서버 또는 클라이언트에) 곳에서만 버그로 인해 발생 . 예외를 던집니다. 책임자가 코드를 수정하도록하십시오.

사례 2 : 일부 외부 종속성으로부터 잘못된 입력이 수신되었습니다. 클라이언트는 전제 조건을 쉽게 확인할 수 있습니다. 예외를 던집니다. 클라이언트가 그 코드에 만족하지 않으면 클라이언트가 코드를 수정하도록합니다.

if(balance>0) 
    myServer.SetBalance(balance); 
else 
    //take appropriate action. 

사례 3 : 나쁜 입력 일부 외부 종속성에서 수신된다. 클라이언트는 전제 조건을 쉽게 확인할 수 없었습니다. 예 : 클라이언트가 서버의 작업 인 문자열을 구문 분석해야합니다. 여기서, 서버가 성공을 반환해야 함을 의미한다 : 아래로 내 대답을 작성 후

bool succeeded = myServer.SetBalance(balance); 
if(!succeeded) 
    //take appropriate action. 

을, 나는이 모든 귀결주의 : 클라이언트는 메소드 SetBalance를 호출-캐치를 시도 사용할 필요가 없습니다 . http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx

편집 : 여기

는 관련 주제에 대한 좋은 읽기입니다 (어느 쪽이 버그 때문에 반환 값을 예외를 catch하거나 전제 조건을 직접 확인하거나 검사하지 않습니다입니다) Jojo는 좋은 지적입니다. 메서드 이름을 TrySetBalance()으로 바꾸면 실패 할 가능성이 있습니다.

0

예외 처리는 런타임 오류 또는 논리 오류 여부와 상관없이 OOP의 오류를 처리하기위한 선택 방법입니다. 예외 처리를 정당화하는 인수 중 하나는 오류 코드가 사용되는 경우 함수 클라이언트가 오류 코드를 확인하는 것을 잊어 버려 쉽게 발견되지 않을 수있는 잠재적 버그로 이어질 수 있다는 것입니다. 반면에 예외 처리가 사용되면 잡히지 않더라도 처리 될 때까지 전파됩니다. 따라서 OOP 순수 주의자는 항상 예외 처리를 사용하여 조언을 제공합니다.

관련 문제