1. 개요
C와 C++ 언어에는 어설션(assertion)을 의미하는 어설션(assert) 키가 있습니다.
Java에는 주장(assertion)을 의미하는 Assert 키워드도 있습니다. 사용법과 의미는 비슷합니다.
2. 문법
Java에서는 Assertion 키워드가 JAVA SE 1.4부터 도입되었습니다. 이전 버전의 Java 코드에서 Assertion 키워드를 사용하여 발생하는 오류를 방지하기 위해 Java에서는 실행 시 기본적으로 Assertion 검사를 활성화하지 않습니다. 무시하세요!), 주장 확인을 활성화하려면 -enableassertions 또는 -ea 스위치를 사용하여 활성화해야 합니다.
Assert 키워드 구문은 매우 간단하며 두 가지 용도로 사용됩니다.
1. <부울 표현식>을 주장합니다.
<부울 표현식>이 true이면 프로그램 실행이 계속됩니다.
false인 경우 프로그램은 AssertionError를 발생시키고 실행을 종료합니다.
2. <부울 표현식>을 주장: <오류 메시지 표현식>
<부울 표현식>이 true이면 프로그램 실행이 계속됩니다.
false인 경우 프로그램은 java.lang.AssertionError를 발생시키고 <오류 메시지 표현>을 입력합니다.
3. 적용사례
사용법을 설명하기 위해 아래에 예제가 제공됩니다.
다음과 같이 코드 코드를 복사합니다 .
공개 클래스 AssertFoo {
공개 정적 무효 메인(문자열 인수[]) {
//어설션 1의 결과가 true이면 실행을 계속합니다.
사실이라고 주장하다;
System.out.println("어설션 1에는 문제가 없습니다. Go!");
System.out.println("/n----/n");
//어설션 2의 결과가 false이고 프로그램이 종료됩니다.
Assert false : "어설션이 실패했습니다. 예외가 발생하면 이 표현식의 정보가 출력됩니다!";
System.out.println("assertion 2에는 문제가 없습니다. Go!");
}
}
코드를 C:/AssertFoo.java에 저장한 후 다음과 같이 실행하고 콘솔 출력을 확인합니다.
1. 프로그램 컴파일:
C:/>javac AssertFoo.java
2. -ea 스위치를 켜지 않고 기본적으로 프로그램이 실행됩니다.
C:/>자바 AssertFoo
주장 1은 괜찮습니다. Go!
------------------
주장 2는 문제가 없습니다. Go!
3. -ea 스위치를 켜고 프로그램을 실행합니다.
C:/>java -ea AssertFoo
주장 1은 괜찮습니다. Go!
------------------
스레드 "main" java.lang.AssertionError의 예외: 어설션이 실패했습니다. 이 표현식의 정보는
예외가 발생하면 출력됩니다!
AssertFoo.main(AssertFoo.java:10)에서
4. 함정
Assert 키워드는 사용하기 쉽지만 Assert를 사용하면 점점 더 깊은 함정에 빠지게 되는 경우가 많습니다. 피해야합니다. 연구를 마친 후 저자는 그 이유를 다음과 같이 요약했습니다.
1. Assert 키워드를 적용하려면 런타임에 명시적으로 활성화해야 합니다. 그렇지 않으면 주장이 의미가 없게 됩니다. 현재 주류 Java IDE 도구는 기본적으로 -ea 어설션 확인 기능을 활성화하지 않습니다. 즉, IDE 도구를 사용하여 코딩을 하면 디버깅 및 실행 시 약간의 문제가 발생한다는 의미입니다. 또한 Java 웹 애플리케이션의 경우 프로그램 코드가 컨테이너에 배포되므로 프로그램 실행을 직접 제어할 수 없습니다. -ea 스위치를 켜야 하는 경우 웹 컨테이너의 실행 구성 매개변수를 변경해야 합니다. 이는 프로그램의 이식과 배포에 큰 불편을 가져온다.
2. if 대신 주장을 사용하는 것은 두 번째 함정입니다. Assert의 판단은 if 문의 판단과 유사하지만 둘의 기능은 본질적으로 다릅니다. Assert 키워드는 프로그램을 테스트하고 디버깅할 때 사용하도록 의도되었지만 실수로 Assert를 사용하여 프로그램의 비즈니스 프로세스를 제어하는 경우 프로그램이 완료되면 테스트 및 디버깅 중에는 사용되지 않습니다. 이는 프로그램의 일반 논리를 수정하는 것을 의미합니다.
3. 어설션 어설션이 실패하면 프로그램이 종료됩니다. 이는 프로덕션 환경에서는 절대 용납되지 않습니다. 프로그램에서 발생할 수 있는 오류는 일반적으로 예외 처리를 통해 해결됩니다. 그러나 어설션을 사용하는 것은 매우 위험합니다. 일단 실패하면 시스템이 중단됩니다.
5. 주장에 대한 생각
Assert는 테스트 프로그램을 디버깅하기 위한 것이지 공식 프로덕션 환경에서 사용하기 위한 것이 아니기 때문에 JUint가 해당 기능을 대체하려면 더 나은 테스트를 고려해야 합니다. JUint는 Assert보다 훨씬 더 많은 핵심 기능을 제공합니다. 물론 디버깅과 테스트는 IDE 디버그를 통해서도 가능합니다. 이런 관점에서 보면 Assert의 미래는 암울합니다.
따라서 언젠가 Java가 기본적으로 -ea 스위치를 지원하지 않는 한 Java에서 Assert 키워드를 사용하지 않는 것이 좋습니다. 그러면 이를 고려할 수 있습니다. 주장이 얼마나 많은 이익을 가져다 줄 수 있는지, 얼마나 많은 문제를 가져올 수 있는지 비교하십시오. 이것이 우리가 그것을 사용할지 여부를 선택하는 원칙입니다.
================================================= ==========
논평:
반면, Validator, junit 등 일부 오픈소스 구성요소에서는 판단 과정에서 Assertion 스타일을 사용하는 것으로 보입니다. 다수의 Assertion이 사용될 가능성이 매우 높지만 작성자는 이를 보기 전에는 확신할 수 없습니다. 소스 코드.
개발 단계에서의 간단한 테스트라면 junit은 편리하고 강력한 도구이므로 자신만의 Assertion을 작성할 때 사용하지 않을 이유가 없습니다.
================================================= ==========
논평:
먼저 단위 테스트 코드에서 사용할 수 있습니다. Junit은 매우 방해적입니다. 전체 프로젝트에서 많은 양의 코드가 Junit을 사용하면 이를 제거하거나 다른 프레임워크를 선택하기가 어렵습니다. 단위 테스트 코드가 많고 이러한 단위 테스트 사례를 재사용하려는 경우 junit 대신 Assert를 선택하여 TestNG와 같은 다른 단위 테스트 프레임워크를 쉽게 사용할 수 있도록 해야 합니다. 같은 이유로 Junit은 정식 함수 코드에 전혀 등장해서는 안 되며, Assert를 사용해야 합니다.
Assert는 주로 기본 클래스, 프레임워크 클래스, 인터페이스 클래스, 핵심 코드 클래스 및 도구 클래스에 적합합니다. 즉, 자신의 코드 호출자가 다른 프로그래머나 다른 서브시스템이 작성한 비즈니스 코드인 경우에 사용해야 합니다. 예를 들어 퀵 정렬 알고리즘을 만든다면
다음과 같이 코드 코드를 복사합니다 .
공개 정적 List<int> QuickSort(List<int> 목록){
목록 주장 != null;
//임시공간 신청
//정렬 시작
for(int i : 목록){
//
}
}
이 경우 들어오는 매개변수의 정확성을 확인하지 않으면 설명할 수 없는 널 포인터 오류가 발생합니다. 호출자는 코드의 세부 사항을 알지 못할 수 있으며 시스템 깊은 곳에서 널 포인터 오류를 디버깅하는 것은 시간 낭비입니다. 전달된 매개변수에 문제가 있음을 호출자에게 직접적이고 명확하게 알려야 합니다. 그렇지 않으면 그는 귀하의 코드에 BUG가 있다고 의심할 것입니다. Assert를 사용하면 두 프로그래머가 자신이 작성한 코드 문제로 인해 서로를 비난하는 것을 방지할 수 있습니다.
주장은 오류가 무엇인지 정확히 알고 있는 오류에 적용되며 귀하와 호출자는 호출자가 오류를 제거하거나 확인해야 한다는 데 동의했습니다. 어설션을 통해 발신자에게 알립니다. 사용자 입력 데이터의 오류나 외부 파일의 형식 오류 등 외부 시스템으로 인해 발생한 오류에는 Assert가 적용되지 않습니다. 이러한 오류는 호출자에 의한 것이 아니라 사용자에 의한 오류이며, 예외도 아닙니다. 왜냐하면 입력 오류와 파일 형식 오류가 흔히 발생하고 이러한 오류는 비즈니스 코드로 확인해야 하기 때문입니다.
Assert는 자주 호출되는 기본 클래스, 프레임워크 코드, 도구 클래스, 핵심 코드 및 인터페이스 코드에 더 적합합니다. 이것이 런타임 시 제거되는 이유입니다. 테스트 코드는 테스트 단계에서 -ea 매개변수를 활성화하여 시스템 깊은 곳의 핵심 코드를 주의 깊게 테스트할 수 있도록 해야 합니다.
Java가 Assert를 덜 사용하는 이유는 Java가 매우 완벽한 OO 시스템을 갖추고 있고 강제 유형 변환이 덜 발생하기 때문에 C처럼 포인터의 유형이 올바른지, 포인터가 비어 있는지 자주 확인할 필요가 없기 때문입니다. 동시에 Java는 메모리나 버퍼를 직접 관리하는 경우가 거의 없으므로 들어오는 버퍼가 비어 있는지 또는 경계를 넘었는지 자주 확인할 필요가 없습니다.
그러나 Assert를 잘 사용하면 프레임워크 코드의 정확성을 향상시키고 프레임워크 코드 사용자의 디버깅 시간을 줄이는 데 도움이 될 수 있습니다.
================================================= =============
논평:
Assert의 목적은 프로그래머가 프로그램의 효율성에 영향을 주지 않고 자신의 논리 오류를 쉽게 발견할 수 있도록 하는 것입니다. Assert로 발견된 오류는 전혀 발생하지 않아야 하며 예외로 대체될 수 없습니다. 예외는 시스템에서 허용되거나 시스템에서 제어할 수 없는 "오류"입니다. 이는 프로그래머의 논리적 문제가 아닙니다.
Assert는 개발 중에 활성화되어야 하며 릴리스 후에는 비활성화되어야 합니다.