Java 트랩의 Assert 키워드에 대한 자세한 설명

1. 개요

C, C++ 언어에는 Assertion이라는 뜻의 Assert 키가 있습니다.
자바에도 Assert 키워드가 있는데, 이는 Assertion을 의미하며 사용법과 의미가 비슷합니다.

2. 구문

Java에서는 이전 버전의 Java 코드에서 Assert 키워드를 사용하여 발생하는 오류를 방지하기 위해 Java에서 Assert 키워드가 도입되었습니다. , 어설션 확인이 활성화되지 않습니다(현재 모든 어설션 문은 무시됩니다!) 어설션 확인을 활성화하려면 -enableassertions 또는 -ea 스위치를 사용하여 활성화해야 합니다.

assert 키워드 구문은 매우 간단하며 두 가지 용도로 사용됩니다.

1.assert 36104a9f3102f9938ad8e7977cc6c5a6
36104a9f3102f9938ad8e7977cc6c5a6이 true이면 프로그램이 계속 실행됩니다.
false인 경우 프로그램은 AssertionError를 발생시키고 실행을 종료합니다.

2. 2bf14352b70ec1d31ee926e886c15565 주장: 3689271d7b41b07e41bda9a90a87b99c
2bf14352b70ec1d31ee926e886c15565이 true이면 프로그램이 계속 실행됩니다.
false인 경우 프로그램은 java.lang.AssertionError를 발생시키고 a062e7d2880a416a7b81ba1c256f7645을 입력합니다.

3. 적용 예시

다음은 사용법을 예시한 것입니다.

public class AssertFoo {
    public static void main(String args[]) {
        //断言1结果为true，则继续往下执行
        assert true;
        System.out.println("断言1没有问题，Go！");

        System.out.println("\n-----------------\n");

        //断言2结果为false,程序终止
        assert false : "断言失败，此表达式的信息将会在抛出异常的时候输出！";
        System.out.println("断言2没有问题，Go！");
    }
}

코드를 C:\AssertFoo.java에 저장한 후 다음과 같이 실행하고 콘솔 출력을 확인합니다.

1. 프로그램 컴파일:
C:>javac AssertFoo.java

2. 프로그램은 -ea 스위치 없이 기본적으로 실행됩니다.
C:>java AssertFoo
어설션 1에는 문제가 없습니다. Go!

------

assertion 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를 사용하는 것이 두 번째 함정입니다. Assert의 판단은 if 문의 판단과 유사하지만 둘의 기능은 본질적으로 다릅니다. Assert 키워드는 프로그램을 테스트하고 디버깅할 때 사용하도록 의도되었지만 실수로 Assert를 사용하여 프로그램의 비즈니스 프로세스를 제어하는 ​​경우 프로그램이 완료되면 테스트 및 디버깅 중에는 사용되지 않습니다. 이는 프로그램의 일반 논리를 수정하는 것을 의미합니다.

3. Assert 어설션이 실패하면 프로그램이 종료됩니다. 이는 프로덕션 환경에서는 절대 용납되지 않습니다. 프로그램에서 발생할 수 있는 오류는 일반적으로 예외 처리를 통해 해결됩니다. 그러나 어설션을 사용하는 것은 매우 위험합니다. 일단 실패하면 시스템이 중단됩니다.


5. Assert에 대한 생각

assert는 테스트 프로그램 디버깅에 사용되며 공식 프로덕션 환경에서는 사용되지 않으므로 이를 대체하기 위해 JUint를 더 나은 테스트하는 것이 좋습니다. JUint가 제공하는 것은 주장보다 훨씬 좋습니다. 물론 IDE 디버그를 통해서도 완벽하게 디버그 및 테스트가 가능합니다. 이런 관점에서 보면 Assert의 미래는 암울합니다.

따라서 언젠가 Java가 기본적으로 -ea 스위치를 지원하지 않는 한 Java에서 Assert 키워드를 사용하지 않는 것이 좋습니다. 주장이 얼마나 많은 이익을 가져다 줄 수 있는지, 얼마나 많은 문제를 가져올 수 있는지 비교하십시오. 이것이 우리가 그것을 사용할지 여부를 선택하는 원칙입니다.

========================================== == ================
댓글:
한편, validator, junit 등 일부 오픈소스 컴포넌트에서는 판단 과정에서 매우 많은 수의 단언문이 사용될 가능성이 있지만 소스 코드를 보지 않고는 확신할 수 없습니다.
개발 단계의 간단한 테스트라면 junit은 편리하고 강력한 도구이므로 직접 Assertion을 작성하고 사용하지 않을 이유가 없습니다.

========================================== == ================
댓글:
은 먼저 단위 테스트 코드에서 사용할 수 있습니다. Junit은 매우 방해적입니다. 전체 프로젝트에서 많은 양의 코드가 Junit을 사용하면 이를 제거하거나 다른 프레임워크를 선택하기가 어렵습니다. 단위 테스트 코드가 많고 이러한 단위 테스트 사례를 재사용하려는 경우 junit 대신 Assert를 선택하여 TestNG와 같은 다른 단위 테스트 프레임워크를 쉽게 사용할 수 있도록 해야 합니다. 같은 이유로 Junit은 정식 함수 코드에 전혀 등장해서는 안 되며,

assert는 주로 기본 클래스, 프레임워크 클래스, 인터페이스 클래스, 핵심 코드 클래스, 도구 클래스에 적합합니다. 즉, 자신의 코드 호출자가 다른 프로그래머나 다른 하위 시스템이 작성한 비즈니스 코드일 때 사용해야 합니다. 예를 들어 퀵 정렬 알고리즘

public static List<int> quickSort(List<int> list){
  assert list != null;
  // 申请临时空间
  //开始排序
  for(int i : list){
      //
  }
}

를 만들 경우, 이 경우 전달된 매개변수의 정확성을 확인하지 않으면 설명할 수 없는 널 포인터 오류가 발생합니다. 호출자는 코드의 세부 사항을 알지 못할 수 있으며 시스템 깊은 곳에서 널 포인터 오류를 디버깅하는 것은 시간 낭비입니다. 전달된 매개변수에 문제가 있음을 호출자에게 직접적이고 명확하게 알려야 합니다. 그렇지 않으면 그는 귀하의 코드에 BUG가 있다고 의심할 것입니다. Assert를 사용하면 두 프로그래머가 자신이 작성한 코드 문제로 인해 서로를 비난하는 것을 방지할 수 있습니다.

어설션은 귀하가 특정 오류를 알고 있으며 귀하와 호출자가 호출자가 오류를 제거하거나 확인해야 한다는 데 동의한 오류에 적용됩니다. 어설션을 통해 호출자에게 알립니다. 사용자 입력 데이터의 오류나 외부 파일의 형식 오류 등 외부 시스템으로 인해 발생한 오류에는 Assert가 적용되지 않습니다. 이러한 오류는 호출자에 의한 것이 아니라 사용자에 의한 오류이며, 예외도 아닙니다. 왜냐하면 입력 오류와 파일 형식 오류가 흔히 발생하고 이러한 오류는 비즈니스 코드로 확인해야 하기 때문입니다.

assert는 자주 호출되는 기본 클래스, 프레임워크 코드, 도구 클래스, 핵심 코드 및 인터페이스 코드에 더 적합합니다. 이것이 런타임 시 제거되는 이유입니다. 테스트 코드는 테스트 단계에서 -ea 매개변수를 활성화하여 시스템 깊은 곳의 핵심 코드를 주의 깊게 테스트할 수 있도록 해야 합니다.

Java가 Assert를 덜 사용하는 이유는 Java가 매우 완벽한 OO 시스템을 갖추고 있고 강제 유형 변환이 덜 자주 발생하기 때문입니다. 따라서 포인터의 유형이 올바른지, 포인터가 올바른지 자주 확인할 필요가 없습니다. C처럼 비어 있습니다. 동시에 Java는 메모리나 버퍼를 직접 관리하는 경우가 거의 없으므로 들어오는 버퍼가 비어 있는지 또는 경계를 넘었는지 자주 확인할 필요가 없습니다.

그러나 Assert를 잘 사용하면 프레임워크 코드의 정확성을 높이고 프레임워크 코드 사용자의 디버깅 시간을 줄이는 데 도움이 될 수 있습니다.

========================================== == ===================
댓글:
assert의 목적은 프로그래머가 효율성에 영향을 주지 않고 자신의 논리 오류를 쉽게 발견할 수 있도록 하는 것입니다. 프로그램. Assert로 발견된 오류는 전혀 발생하지 않아야 하며 예외로 대체될 수 없습니다. 예외는 시스템에서 허용되거나 시스템에서 제어할 수 없는 "오류"입니다. 이는 프로그래머의 논리적 문제가 아닙니다.

개발 중에는 Assert를 활성화하고 출시 후에는 비활성화해야 합니다.

자바 트랩의 Assert 키워드에 대한 자세한 설명과 관련 글은 PHP 중국어 홈페이지를 참고해주세요!