메소드에 null 전달 [closed]

StackOverflow https://stackoverflow.com/questions/32280

  •  09-06-2019
  •  | 
  •  

문제

저는 우수한 클린 코드 를 읽는 중입니다.

한 가지 논의는 null을 메소드에 전달하는 것입니다. 라코 디스

이를 처리하는 다양한 방법을 나타냅니다. 라코 디스

어설 션 접근 방식을 선호합니다.하지만 어설 션이 기본적으로 꺼져 있다는 사실이 마음에 들지 않습니다.

이 책은 마지막으로 다음과 같이 말합니다. <인용구>

대부분의 프로그래밍 언어에서는 호출자가 실수로 전달한 null을 처리하는 좋은 방법이 없습니다.이것이 사실이기 때문에 합리적인 접근 방식은 기본적으로 null 전달을 금지하는 것입니다.

이 제한을 어떻게 시행 할 것인지에 관한 것이 아닙니다.

어느 쪽이든 강한 의견을 가진 사람이 있습니까?

도움이 되었습니까?

해결책

어설 션 사용과 예외 발생 모두 여기서 유효한 접근 방식입니다. 여기에서와 같이 어떤 메커니즘이든 런타임 오류가 아닌 프로그래밍 오류를 나타내는 데 사용할 수 있습니다.

  • 어설 션은 일반적으로 프로덕션 시스템에서 비활성화되므로 성능상의 이점이 있습니다.
  • 예외는 검사가 항상 수행되므로 안전하다는 이점이 있습니다.

    선택은 실제로 프로젝트의 개발 관행에 달려 있습니다. 프로젝트 전체는 어설 션 정책을 결정해야합니다. 모든 개발 중에 어설 션을 사용하도록 선택하는 경우 어설 션을 사용하여 이러한 종류의 잘못된 매개 변수를 확인합니다. 프로덕션 시스템에서 다음으로 인해 NullPointerException이 발생합니다. 프로그래밍 오류는 어차피 의미있는 방식으로 포착 및 처리 될 가능성이 낮으므로 어설 션처럼 작동합니다.

    실제적으로 저는 어설 션이 적절할 때 활성화 될 것이라고 믿지 않는 많은 개발자를 알고 있으므로 NullPointerException을 throw하는 안전을 선택합니다.

    물론 코드에 대한 정책을 시행 할 수없는 경우 (예를 들어 라이브러리를 만드는 중이고 다른 개발자가 코드를 실행하는 방식에 따라 달라지는 경우) 안전한 던지기 접근 방식을 선택해야합니다. 라이브러리 API의 일부인 메소드에 대한 NullPointerException.

다른 팁

일반적인 규칙은 메서드가 null 인수를 예상하지 않는 경우 System.ArgumentNullException .적절한 Exception를 던지면 리소스 손상 및 기타 나쁜 일로부터 보호 할뿐만 아니라 코드 디버깅에 소요되는 시간을 절약하는 코드 사용자를위한 가이드 역할을합니다.

방어 프로그래밍 에 대한 기사도 읽어보세요.

또한 즉시 사용되지는 않지만 Spec #에 대한 언급과 관련이 있습니다 ... Java의 차기 버전에 "null-safe 유형"을 추가하는 제안이 있습니다. "향상된 널 처리-널 안전 유형 ".

제안에 따라 귀하의 방법은 다음과 같습니다. 라코 디스

여기서 #Point는 null 유형의 객체에 대한 non-Point 참조 유형입니다.

<인용구>

이 제한을 어떻게 시행 할 것인지에 관한 것이 아닙니다.

ArgumentExcexception null을 전달합니다. 라코 디스

저는 주장 사용을 선호합니다.

공개 및 보호 방법에서만 어설 션을 사용하는 규칙이 있습니다.호출하는 메서드가 유효한 인수를 private 메서드에 전달하는지 확인해야하기 때문입니다.

사양 번호가 매우 흥미로워 보입니다!

사용할 수없는 경우 일반적으로 런타임 null 검사를 사용하여 비공개 메서드가 아닌 메서드를 테스트하고 내부 메서드에 대한 어설 션을 테스트합니다.각 메서드에서 명시 적으로 null 검사를 코딩하는 대신 null 검사 메서드를 사용하여 유틸리티 클래스에 위임합니다. 라코 디스

그런 다음 확인은 다음과 같이 바뀝니다. 라코 디스

그 는 편집기 매크로 또는 코드 처리 스크립트로 추가 할 수 있습니다. 수정 : 이 방법으로 상세 검사를 추가 할 수도 있지만 한 줄 추가를 자동화하는 것이 훨씬 더 쉽다고 생각합니다.

<인용구>

대부분의 프로그래밍 언어에서는 호출자가 실수로 전달한 null을 처리하는 좋은 방법이 없습니다.이것이 사실이기 때문에 합리적인 접근 방식은 기본적으로 null 전달을 금지하는 것입니다.

지금까지 JetBrains 의 @Nullable 및 @NotNull 주석 접근 방식을 발견했습니다.안타깝게도 IDE 전용이지만 정말 깨끗하고 강력한 IMO입니다.

http://www.jetbrains.com/idea/documentation/howto.html

이것 (또는 비슷한 것)을 자바 표준으로 사용하면 정말 좋을 것입니다.

엄격하게 관련이있는 것은 아니지만 Spec # 을 살펴 보시기 바랍니다.

아직 개발 중이라고 생각하지만 (Microsoft에서) 일부 CTP를 사용할 수 있으며 유망 해 보입니다.기본적으로 다음을 수행 할 수 있습니다. 라코 디스

또는 라코 디스

또한 Notnull 유형과 같은 다른 기능도 제공합니다..NET Framework 2.0을 기반으로 빌드되었으며 완전히 호환됩니다.보시다시피 구문은 C #입니다.

@Chris Karcher 절대적으로 맞습니다.내가 말할 유일한 것은 매개 변수를 개별적으로 확인하고 예외가 null 인 매개 변수를보고하도록하는 것입니다. 이는 null이 어디서 오는지 훨씬 쉽게 추적 할 수 있기 때문입니다.

@wvdschel 와우!코드를 작성하는 것이 너무 힘들다면 PostSharp (또는 Java와 동등한가능한 경우) 어셈블리를 사후 처리하고 매개 변수 검사를 삽입 할 수 있습니다.

주제에서 벗어난 것이 화제가 된 것처럼 보이므로 Scala는 이에 대해 흥미로운 접근 방식을 취합니다.null 일 수 있음을 나타 내기 위해 Option로 명시 적으로 래핑하지 않는 한 모든 유형은 null이 아닌 것으로 간주됩니다.그래서 : 라코 디스

저는 일반적으로 작업 속도를 늦추기 때문에 둘 다하지 않는 것을 선호합니다.어쨌든 나중에 NullPointerExceptions가 발생하여 사용자가 null을 메서드에 전달하고 있음을 빠르게 알 수 있습니다.나는 확인하곤했지만 내 코드의 40 %가 코드를 확인하는 것으로 끝났고, 그 시점에서 좋은 주장 메시지가 가치가 없다고 판단했습니다.

wvdschel의 게시물 에 동의하거나 동의하지 않습니다. 이는 그가 구체적으로 말하는 내용에 따라 다릅니다.

이 경우 확실히이 메소드는 null에서 충돌하므로 여기에서 명시적인 검사가 필요하지 않을 수 있습니다.

그러나 메소드가 단순히 전달 된 데이터를 저장하고 나중에이를 처리 할 다른 메소드가있는 경우 불량 입력을 가능한 한 빨리 발견하는 것이 버그를 더 빨리 수정하는 열쇠입니다 .나중에 잘못된 데이터가 수업에 제공되는 수많은 방법이있을 수 있습니다.사실 이후에 쥐가 어떻게 당신의 집에 들어 왔는지 알아 내고 어딘가에 구멍을 찾으려고하는 것입니다.

약간 주제에서 벗어 났지만 매우 유용하다고 생각되는 findbugs 의 한 가지 기능은null 값이 전달되지 않아야하는 매개 변수를 설명하기 위해 메소드의 매개 변수에 주석을 추가합니다.

코드의 정적 분석을 사용하여 findbugs 는 잠재적으로 null 값으로 메서드가 호출되는 위치를 가리킬 수 있습니다.

두 가지 장점이 있습니다.

  1. 주석은 메소드 호출 방법에 대한 사용자의 의도를 설명하며 문서를 지원합니다.
  2. FindBugs는 잠재적 인 버그를 추적 할 수 있도록 메서드의 잠재적 인 문제 호출자를 가리킬 수 있습니다.

    메소드를 호출하는 코드에 액세스 할 수있을 때만 유용하지만 일반적으로 그렇습니다.

방법의 시작 부분에 C # ArgumentException 또는 Java IllegalArgumentException를 던지는 것은 저에게 가장 명확한 솔루션으로 보입니다. 메소드 서명에 선언되지 않은 예외 인 런타임 예외에 항상주의해야합니다.컴파일러는 이것을 잡도록 강요하지 않기 때문에 잊어 버리기 쉽습니다.소프트웨어가 갑자기 중지되는 것을 방지하기 위해 일종의 "모두 잡기"예외 처리가 있는지 확인하십시오.이것이 사용자 경험에서 가장 중요한 부분입니다.

이를 처리하는 가장 좋은 방법은 예외를 사용하는 것입니다.궁극적으로 어설 션은 최종 사용자에게 유사한 경험을 제공하지만 최종 사용자에게 예외를 표시하기 전에 코드를 호출하는 개발자가 상황을 처리 할 수있는 방법을 제공하지 않습니다.Ultimatley, 가능한 한 빨리 (특히 공개 코드에서) 유효하지 않은 입력을 테스트하고 호출 코드가 포착 할 수있는 적절한 예외를 제공하려고합니다.

Java 방식에서 null이 프로그래밍 오류에서 비롯된 것으로 가정하고 (즉, 테스트 단계를 벗어나면 안 됨) 시스템이이를 던지거나 해당 지점에 도달하는 부작용이있는 경우 null을 확인합니다.IllegalArgumentException 또는 NullPointerException을 발생시킵니다.

Null이 실제 예외 의 경우에서 올 수 있지만 확인 된 예외를 사용하고 싶지 않은 경우 메서드 시작 부분에서 IllegalArgumentException 경로를 사용하는 것이 좋습니다..

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top