함수 인수를 확인 하시겠습니까? 정기적으로

Question

, 내 함수 인수의 유효성을 검사 : 물론

public static void Function(int i, string s) 
{ 
    Debug.Assert(i > 0); 
    Debug.Assert(s != null); 
    Debug.Assert(s.length > 0); 
} 

검사 함수의 맥락에서 "유효"입니다.

일반적인 업계 관행입니까? 함수 인수 유효성 검사와 관련된 일반적인 관행은 무엇입니까?

Answer 1

허용되는 관행은

ArgumentException 
ArgumentNullException 
ArgumentOutOfRangeException 

Answer 2

나는 업계 표준에 말을하지 않습니다,하지만 당신은 바닥이 한 줄에 주장 결합 할 수 있습니다 :

Debug.Assert(!String.IsNullOrEmpty(s)); 

Answer 3

는 차라리 내가 경비를 쓰기 Debug.Assert를 사용하지 않도록하려고합니다. 함수 매개 변수가 예상 값이 아니면 함수를 종료합니다. 이와 같이 :

public static void Function(int i, string s) 
{ 
    if(i <= 0) 
    { 
     /*exit and warn calling code */ 
    } 
} 

나는 이것이 일어날 필요가있는 논쟁의 양을 줄인다.

Answer 4

대개의 경우 Debug.Assert를 사용하지 않고 이와 같은 작업을 수행합니다.

public static void Function(int i, string s) 
{ 
    if (i > 0 || !String.IsNullOrEmpty(s)) 
     Throw New ArgumentException("blah blah"); 
} 

경고 : 이것은 에어 코드이므로 테스트를 거치지 않았습니다.

Answer 5

실시간 응용 프로그램에서 데이터 유효성을 검사하기 위해 어설 션을 사용해서는 안됩니다. 어설 션은 함수가 적절한 방법으로 사용되는지 여부를 테스트하기위한 것입니다. 또는 함수가 적절한 값을 반환하는지 확인합니다. 당신이 얻고있는 가치는 당신이 기대 한 것입니다. 그들은 테스트 프레임 워크에서 많이 사용됩니다. 그들은 시스템이 느릴 때 배치 될 때 꺼지기위한 것입니다. 잘못된 케이스를 처리하려면 위의 포스터와 같이 명시 적으로 처리해야합니다.

Answer 6

네트워크를 통해 또는 프로세스 간 통신을 통해 호출 할 수있는 코드는 매개 변수 유효성 검사가 필요합니다. 그렇지 않으면 보안 취약점 일 수 있기 때문에 디버그 빌드 만 검사하기 때문에 Debug.Assert 예외를 throw해야합니다.

다른 사람이 사용할 코드는 유효하지 않은 값을 전달할 때 버그임을 알기 때문에 매개 변수 유효성 검사가 필요합니다. 이번에도 예외를 던져야합니다. 좋은 설명은 그들이 잘못한 것을 설명하고 그것을 고치는 방법에 대한 설명과 함께 예외입니다.

Debug.Assert는 디버깅을 돕기위한 것일뿐 첫 번째 방어선이지만 "실제"유효성 검사는 아닙니다.

다음과

if(i < 0) 
    throw new ArgumentOutOfRangeException("i", "parameter i must be greater than 0"); 

if(string.IsNullOrEmpty(s)) 
    throw new ArgumentNullException("s","the paramater s needs to be set ..."); 

그래서 기본 인수 예외 목록이 될 때 : 값이 유효하지 않거나 나중에 예외가 발생한다면 다음과 같이

Answer 7

무엇 당신이 썼다는 전제 조건은이고 필수 요소는 계약 번호입니다. 그 용어에 대한 Google (또는 "StackOverflow":) 및 그 정보에 대한 좋은 정보와 나쁜 정보가 많이 있습니다. 이 방법에는 사후 조건 및 클래스 불변의 개념도 포함됩니다.

어설 션이 유효한 메커니즘이라는 점을 분명히하십시오.

물론 보통은 (not always) 이 아닙니다.은 릴리스 모드로 검사되었으므로 릴리스하기 전에 코드를 테스트해야합니다.

어설 션을 사용하도록 설정하고 어설 션을 위반하면 어설 션을 사용하는 일부 언어 (및 특히 에펠에서)의 표준 동작은 어설 션 위반 예외를 throw하는 것입니다.

어설 션을 선택하지 않은 경우 이 아닌 코드 라이브러리를 게시하는 경우 편리하거나 권장할만한 메커니즘이거나 부정확 한 직접 입력을 유효화하는 방법 (분명히)이 아닙니다. "잘못된 입력"이있는 경우 프로그램의 정상적인 동작의 일부로 입력 유효성 검사 레이어을 디자인해야합니다. 내부 모듈에서 어설 션을 자유롭게 사용할 수 있습니다. 그들이 잘못라면

---

다른 언어, 자바처럼,이 언어에 의해 강력한 ""주장 "또는 디자인이없는 주로하기 때문에, 명시 적으로 확인 인수의 전통의 더 예외를 던지고있다 계약 "전통.

는 (그것은 몇 가지 이상한 것처럼 보일 수 있습니다, 그러나 나는 반드시 악 존경, 그리고 전통의 차이를 찾을 수 있습니다.)

참조에게 또한 this related question합니다.

Answer 8

공용 함수 특히 API 호출의 경우 예외를 throw해야합니다. 소비자는 코드에 버그가 있음을 알고있을 것입니다. 예외는 보장 된 방법입니다.

내부 또는 개인 기능의 경우 Debug.Assert가 좋습니다 (IMO는 필요하지 않음). 알 수없는 매개 변수를 가져 오지 않으며 예상 한 출력에 의해 잘못된 값을 잡아야합니다. 그러나 때로는 Debug.Assert를 사용하면 훨씬 빨리 버그를 수정하거나 방지 할 수 있습니다.

API 호출이 아닌 공용 함수 나 다른 호출자가 호출하는 내부 메소드의 경우에는 어느쪽으로 갈 수 있습니다. 나는 일반적으로 public 메서드에 대한 예외를 선호하며 (보통) 내부 메서드가 예외없이 수행되도록합니다. 내부 방법이 특히 오용되기 쉬운 경우 예외가 보장됩니다.

인수의 유효성을 검사하는 동안 동기화 상태를 유지하고 (perf penalty를 지불해야하는) 4 단계의 유효성 검사를 원하지 않습니다. 따라서 외부 인터페이스에서 유효성을 검사하여 동료와 동료가 함수를 적절하게 호출하거나 필연적으로 발생하는 버그를 수정할 수 있다고 신뢰하십시오.

Answer 9

프로그래밍 방식 가정을 확인하려면 Assert를 사용해야합니다. 그

1. 당신이 당신이 것을 다시 한 번 확인 할 수

어설 문에 들어가 불가능한 상태이어야한다 그 방법

를 호출하는 단 하나있는 상황이며, 불가능한 상태에 도달하지 못합니다. 검증하지 않고 편안하게 느낄 수있는 곳에 사용하십시오.

함수에 잘못된 인수가 있지만 상황에 따라 (예 : 누군가 다른 사람이 해당 코드를 호출 할 수있는 경우) 값을받을 수 없다는 것을 알 수있는 경우 예외를 throw해야합니다 (a la @Nathan W 및 @Robert Paulson) 또는 정상적으로 실패합니다 (a la @Srdjan Pejic).