부정 인수예외 또는 Null Pointernull 매개 변수에 대한 예외입니까?

부정 인수예외 또는 Null Pointernull 매개 변수에 대한 예외입니까?

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

5년 전에 문을 닫았어요

이 질문을 개선하다

속성에 대한 간단한 세터 메서드가 있으며null이 특정 속성에는 적합하지 않습니다.저는 항상 이 상황에서 고민해 왔습니다.javadocs에서, 또는 ?를 던질까요?둘 다 적절한 것 같습니다.뭔가 알려진 기준이 있나요?아니면 이것은 당신이 원하는 모든 것을 해야 하는 일 중 하나이고 둘 다 정말 옳은 일인가요?

사용하셔야 합니다.IllegalArgumentException(IAE), 없음NullPointerException(NPE)에는 다음과 같은 이유가 있습니다.

먼저 NPE JavaDoc은 NPE가 적절한 경우를 명시적으로 나열합니다.이 모든 것이 런타임에 의해 느려지는 것에 주의해 주세요.null부적절하게 사용되고 있습니다.이와는 대조적으로 IAE JavaDoc은 "메서드가 불법 또는 부적절한 인수를 전달했음을 나타내는 Thrown"이라고 더 이상 명확하게 말할 수 없습니다.그래, 너구나!

다음으로 스택 트레이스에 NPE가 있는 경우 무엇을 상정하고 있습니까?아마 누군가가 그 사람을 부정했을 겁니다nullIAE가 표시될 경우 스택 상단의 메서드 발신자가 부정한 값으로 전달되었다고 가정합니다.다시, 후자의 가정은 사실이고, 전자는 오해를 불러일으킨다.

셋째, IAE는 파라미터를 검증하기 위해 명확하게 설계되어 있기 때문에 이를 예외의 기본 선택으로 간주해야 하는데 왜 NPE를 선택해야 합니까?물론 동작에 따라서는 다릅니다.발신 코드가 IAE와 별도로 NPE를 포착하여 그 결과 뭔가 다른 것을 할 수 있다고 생각하십니까?좀 더 구체적인 오류 메시지를 전달하려고 합니까?단, 다른 모든 잘못된 파라미터와 마찬가지로 예외 메시지텍스트에서도 이 작업을 수행할 수 있습니다.

넷째, 다른 모든 잘못된 파라미터 데이터는 IAE가 되므로 일관성을 유지하는 것이 어떻습니까?왜 이렇게 불법적인가?null너무 특별해서 다른 모든 종류의 불법 논쟁과는 별도로 예외를 둘만 한 것인가?

마지막으로 Java API의 일부가 NPE를 이와 같이 사용한다는 다른 답변의 주장을 받아들입니다.그러나 Java API는 예외 유형부터 명명 규칙까지 모든 것에 일관성이 없기 때문에 무작정 Java API를 복사하는 것(가장 좋아하는 부분)만으로는 이러한 고려 사항을 능가할 수 없다고 생각합니다.

뭔가...IllegalArgumentException원하지 않으면 호출됩니다.null허용되는 값이 될 수 있습니다.NullPointerException만약 당신이 변수를 사용하려 한다면, 그것은 던져질 것이다.null.

표준이 되는 것은 투척하는 것입니다.NullPointerException일반적으로 오류가 없는 "유효한 자바"는 이를 항목 42(제1판), 항목 60(제2판), 또는 항목 72(제3판)"에서 간략히 설명합니다.

모든 잘못된 메서드 호출은 결국 불법적인 논쟁이나 불법적인 상태로 귀결되지만 다른 예외는 일반적으로 특정 종류의 불법적인 논쟁이나 상태에 사용된다.null 값이 금지된 파라미터에서 발신자가 null을 전달하면 규칙에 따라 null Pointer가 지정됩니다.IlgalArgument가 아닌 예외가 발생함예외입니다.

나는 던지는 것에 전적으로 찬성했다.IllegalArgumentExceptionNULL 파라미터의 경우, 오늘까지,java.util.Objects.requireNonNullmethod를 지정합니다.이 방법에서는 다음 작업을 수행하는 대신

if (param == null) {
    throw new IllegalArgumentException("param cannot be null.");
}

다음 작업을 수행할 수 있습니다.

Objects.requireNonNull(param);

그리고 그것은 그것을 던질 것이다.NullPointerException전달한 파라미터가null.

그 방법이 바로 그 중간이라는 것을 고려하면java.util그 존재는 투척이 매우 강력하다는 증거라고 생각합니다NullPointerException"자바의 작업 방식"입니다.

어쨌든 결심한 것 같아요.

하드 디버깅에 관한 인수는 거짓임을 주의해 주십시오.물론, 이 인수에 대해서는,NullPointerException무엇이 무효이고 왜 무효가 되지 말아야 하는지 말하는 거죠와 마찬가지로IllegalArgumentException.

의 추가 장점 중 하나는NullPointerException고성능 크리티컬 코드에서는 null(및 null)에 대한 명시적 검사를 생략할 수 있습니다.NullPointerException에러 메시지와 함께)에 의존합니다.NullPointerExceptionnull 파라미터의 메서드를 호출하면 자동으로 표시됩니다.메서드를 신속하게 호출하면(즉, 빠르게 실패하면), 기본적으로 동일한 효과를 얻을 수 있습니다.개발자에게 그다지 편리한 것은 아닙니다.대부분의 경우 명시적으로 체크하고 어떤 파라미터가 늘인지 나타내는 유용한 메시지와 함께 던지는 것이 좋지만, 메서드/컨스트럭터의 공개 계약을 위반하지 않고 퍼포먼스가 요구되면 변경할 수 있는 옵션이 있는 것은 좋습니다.

저는 JDK 라이브러리, 특히 Collections and Concurrency(Joshua Bloch, Doug Lea, 그들은 견고한 API를 설계할 줄 안다)의 설계를 따르는 경향이 있습니다.어쨌든 JDK의 많은 API는 프로 액티브하게 송신합니다.NullPointerException.

예를 들어 Javadoc forMap.containsKey상태:

@throws Null Pointer키가 늘이고 이 맵에서 늘키를 허용하지 않는 경우는 예외입니다(옵션).

자신의 NPE를 던지는 것은 완전히 유효합니다.이 규칙은 예외 메시지에 늘이었던 파라미터 이름을 포함하도록 되어 있습니다.

패턴은 다음과 같습니다.

public void someMethod(Object mustNotBeNull) {  
    if (mustNotBeNull == null) {  
        throw new NullPointerException("mustNotBeNull must not be null");  
    }  
}

어떤 방법으로든 잘못된 값을 설정하지 않도록 하고 나중에 다른 코드가 이 값을 사용하려고 할 때 예외를 발생시킵니다.디버깅은 악몽이 됩니다.항상 fail-fast 원칙을 따라야 합니다.

Jason Cohen의 주장이 잘 제시되었기 때문에 찬성표를 던졌습니다.차근차근 분할해 봅시다.;-)

• NPE JavaDoc은 명시적으로 "null 객체의 다른 잘못된 사용"이라고 말합니다.실행 시 null이 발생하지 않아야 할 상황에만 국한된다면 이러한 모든 경우를 훨씬 더 간결하게 정의할 수 있습니다.

• 잘못된 것을 가정하면 어쩔 수 없지만 캡슐화가 적절하게 적용된다고 가정할 때, null이 부적절하게 참조되었는지 여부나 메서드가 부적절한 null을 검출하여 예외를 발생시켰는지 여부에 대해 신경 쓰거나 주의할 필요가 없습니다.

• IAE보다 NPE를 선택하는 이유는 여러 가지가 있습니다.

  • 불법 운영의 성격에 대해 더 구체적이다.
  • Null을 잘못 허용하는 논리는 잘못된 값을 허용하는 논리와 매우 다른 경향이 있습니다.예를 들어 사용자가 입력한 데이터를 검증할 때 허용되지 않는 값을 얻으면 해당 오류의 원인은 애플리케이션의 최종 사용자에게 있습니다.NULL이 되면 프로그래머 오류입니다.
  • 유효하지 않은 값은 스택오버플로우, 메모리 부족 오류, 해석 예외 등의 원인이 될 수 있습니다.실제로 대부분의 오류는 보통 어떤 시점에서 메서드콜에서 비활성값으로 나타납니다.따라서 IAE는 런타임에 있는 모든 예외 중 MOST GENERAL로 간주됩니다.예외.

• 실제로 다른 잘못된 인수는 다른 모든 종류의 예외를 초래할 수 있습니다.UnknownHostException, FileNotFoundException, 다양한 구문 오류 예외, IndexOutOfBoundsException, 인증 실패 등

일반적으로 NPE는 전통적으로 Fail Fast 원칙을 따르지 않는 코드와 관련되어 있기 때문에 매우 악의가 있다고 생각합니다.게다가 JDK가 NPE를 메시지 문자열로 채우지 못한 것이 원인이 되지 않는 강한 부정적인 감정을 불러일으켰습니다.실제로 런타임 관점에서 NPE와 IAE의 차이는 엄밀히 말하면 이름입니다.이 관점에서는, 이름을 정확하게 말할수록, 발신자에게 보다 명확한 정보를 제공할 수 있습니다.

"Holy War" 스타일의 질문입니다.다시 말해, 두 가지 대안 모두 좋지만, 사람들은 죽음을 각오하고 방어할 수 있는 그들의 선호가 있을 것이다.

의 경우setter방법 및null전달이 되고 있기 때문에, 제 생각에는 더 많은 사람들이 하는 게IllegalArgumentException.aNullPointerException실제로 사용하려고 하는 경우에는 더 말이 되는 것 같습니다.null.

그래서 이걸 쓰고 있으면null,NullPointer만약 그것이 통과되고 있고, 그리고 그것은null,IllegalArgument.

Apache Commons Lang에 NullArgument가 있습니다.여기서 설명하는 몇 가지 작업을 수행하는 예외: Ilgal Argument를 확장합니다.예외 및 예외의 유일한 생성자는 null이 아니어야 할 인수 이름을 사용합니다.

NullArgument 같은 걸 던지는 게예외 또는 부정 인수예외는 예외적인 상황을 더 정확하게 기술하고, 나와 동료들은 그 주제에 대한 블로흐의 조언을 따르기로 결정했다.

지금 하고 있는 말에 전적으로 동의해.일찍 실패하면 빨리 실패한다.꽤 좋은 예외의 주문이야

어떤 예외를 던질 것인가에 대한 질문은 대부분 개인적인 취향의 문제이다.내 생각에는 불법적인 주장예외는 메서드에 전달한 인수에 문제가 있는 것이지 메서드 실행 중에 생성되었을 가능성이 있는 값에 문제가 있는 것이 아니기 때문에 NPE를 사용하는 것보다 더 구체적인 것으로 보입니다.

마이 투센트

사실, Illigal Argument를 던지는 문제는예외 또는 Null Pointer제 겸손한 견해로는 자바에서의 예외처리에 대한 이해가 부족한 소수에게만 '성전'이 될 뿐입니다.일반적으로 규칙은 다음과 같이 단순합니다.

• 인수 제약 위반은 디버깅이 훨씬 어려운 부정한 상태를 피하기 위해 가능한 한 빨리(-> fast fail) 표시해야 합니다.
• 어떤 이유로든 유효하지 않은 null 포인터가 있는 경우 null Pointer를 던집니다.예외.
• 잘못된 어레이/수집 인덱스의 경우 ArrayIndexOutOfBounds를 슬로우합니다.
• 어레이/수집 크기가 음수인 경우 Negative Array Size를 슬로우합니다.예외.
• 위의 내용에 포함되지 않은 부정 인수와 더 구체적인 예외 유형이 없는 경우에는 Ilgal Argument를 던집니다.휴지통으로서의 예외
• 한편, Fast Fail로 회피할 수 없는 WINDE A FILD 내의 제약 위반의 경우는, IlgalStateException 또는 보다 구체적인 체크 마크를 붙인 예외로서 캐치 해 주세요.원래 Null Pointer를 통과시키지 않음예외: 이 경우 ArrayIndexOutOfBounds 등!

모든 종류의 인수 제약 위반을 IlgalArgument에 매핑하는 경우 최소 3가지 타당한 이유가 있습니다.예외입니다. 세 번째는 아마도 잘못된 스타일을 나타낼 정도로 심각합니다.

(1) 프로그래머는 인수 제약 위반의 모든 사례가 IlgalArgument를 초래한다고 안전하게 가정할 수 없다.예외는 이용 가능한 특정 유형의 예외가 더 이상 없는 경우 대다수의 표준 분류가 휴지통으로 사용하지 않고 이 예외를 사용하기 때문이다.인수 제약 조건 위반의 모든 사례를 IlgalArgument에 매핑하려고 합니다.API의 예외는 클래스를 사용하는 프로그래머의 좌절로 이어질 뿐입니다.표준 라이브러리는 대부분 다른 규칙을 따르고 대부분의 API 사용자도 이러한 규칙을 사용합니다.

(2) 예외를 매핑하면 실제로 단일 상속으로 인해 다음과 같은 다른 종류의 이상이 발생합니다.모든 Java 예외는 클래스이므로 단일 상속만 지원합니다.따라서 실제로 둘 다 Null Pointer라고 하는 예외를 만드는 방법은 없습니다.예외 및 Illgal Argument예외. 서브클래스는 둘 중 하나에서만 상속할 수 있습니다.불법 인수의 투척따라서 null 인수의 경우는 예외입니다.예를 들어 콜 반복에 기본값을 입력하는 등 프로그램에서 문제를 프로그램적으로 수정하려고 할 때마다 API 사용자가 문제를 구별하기가 어렵습니다.

(3) 매핑은 실제로 버그 마스킹의 위험을 발생시킵니다.인수 제약 위반을 IlgalArgument에 매핑하려면예외입니다. 제약이 있는 인수를 가진 모든 메서드 내에서 외부 트라이캐치를 코드화해야 합니다.그러나 단순히 런타임만 잡는다면문서화된 런타임 매핑 위험이 있으므로 이 캐치 블록의 예외는 불가능합니다.IlgalArgument에 사용된 자유방임 메서드에 의해 발생하는 예외예외는 인수 제약 위반이 원인이 아닌 경우에도 마찬가지입니다.따라서 매우 구체적일 필요가 있지만, 그 노력조차도 실수로 다른 API의 문서화되지 않은 런타임 예외(버그 등)를 IlgalArgument에 매핑하는 경우로부터 보호되지 않습니다.사용하시는 API는 예외입니다.따라서 가장 세심한 매핑이라도 메서드 사용자의 인수 제약 위반으로 다른 라이브러리 메이커의 프로그래밍 오류를 마스킹할 위험이 있습니다.이것은 단순한 촌스러운 동작입니다.

반면 표준 관행에서는 규칙은 단순하고 예외 원인은 마스크되지 않고 구체적입니다.메서드 호출자에게는 규칙도 간단합니다.부정한 값을 전달했기 때문에 어떤 종류의 문서화된 런타임 예외가 발생했을 경우 기본값으로 콜을 반복하거나(이러한 특정 예외는 필수), 또는 코드를 수정합니다.반면, 문서화되어 있지 않은 런타임 예외를 fo에서 발생하는 경우는, 다음과 같습니다.특정 인수 세트를 사용하여 메서드 제조자에게 오류 보고서를 제출하여 코드 또는 문서 중 하나가 수정되었는지 확인합니다.

주관적인 질문으로 이 질문은 종료되어야 하지만 아직 진행 중이기 때문에 다음과 같습니다.

이것은 이전 직장에서 사용한 내부 정책의 일부이며, 매우 효과가 있었습니다.이것은 모두 기억에서 나온 것이기 때문에 정확한 문구를 기억할 수 없습니다.체크된 예외를 사용하지 않았다는 점은 주목할 필요가 있지만 질문의 범위를 벗어납니다.그들이 사용한 체크되지 않은 예외는 크게 세 가지 범주로 분류된다.

특수한 포인터예외:일부러 던지지 마세요.NPE는 늘 참조를 해제할 때만 VM에 의해 느려집니다.이것들은 절대 던져지지 않도록 모든 가능한 노력을 기울여야 한다.@Nullable 및 @NotNull을 코드 분석 도구와 함께 사용하여 이러한 오류를 찾아야 합니다.

부정 인수예외:함수에 대한 인수가 공개 매뉴얼에 준거하지 않을 때 느려집니다.이것에 의해, 에러는 건네진 인수에 근거해 특정되어 기술됩니다.OP의 상황은 이 범주에 속합니다.

InlawalStateException:함수가 호출되고 해당 인수가 전달될 때 예기치 않은 경우 또는 메서드가 속한 객체의 상태와 호환되지 않을 때 느려집니다.

예를 들어 길이가 있는 항목에 사용되는 IndexOutOfBoundsException의 내부 버전이 두 개 있습니다.인덱스가 길이보다 클 경우 사용되는 IlgalStateException 서브클래스 중 하나.IlgalArgument의 다른 서브클래스는예외: 인덱스가 음수인 경우 사용됩니다.이는 개체에 항목을 더 추가할 수 있고 인수는 유효하지만 음수는 유효하지 않기 때문입니다.

말씀드렸듯이 이 시스템은 매우 잘 작동하고 있습니다.왜 차이가 나는지 설명하는데 누군가가 필요했습니다.오류의 종류에 따라 어떻게 해야 할지 쉽게 알 수 있습니다.실제로 무엇이 잘못되었는지 파악할 수 없는 경우에도 오류를 포착하고 추가 디버깅 정보를 생성할 수 있습니다."

특수한 포인터예외:NPE가 느려지지 않도록 Null 대소문자를 처리하거나 어설션을 입력합니다.만약 당신이 주장을 넣는다면 그것은 다른 두 가지 유형 중 하나일 뿐이다.가능하면 애설션이 처음부터 있었던 것처럼 디버깅을 계속합니다.

부정 인수예외: 콜 사이트에 문제가 있습니다.전달되는 값이 다른 함수의 값일 경우 잘못된 값을 수신하는 이유를 확인합니다.인수 중 하나를 전달하면 예상한 값을 반환하지 않는 함수를 찾을 때까지 오류 체크업으로 콜스택을 체크합니다.

InlawalStateException:함수를 올바른 순서로 호출하지 않았습니다.인수 중 하나를 사용하는 경우 해당 인수를 체크하고 IlgulateArgument를 슬로우합니다.문제를 설명하는 예외입니다.그런 다음 문제가 발견될 때까지 뺨을 스택에 대고 전파할 수 있습니다.

어쨌든 그의 요점은 IlgulateArgumentAssentions를 스택에 복사할 수 있다는 것이었습니다.Illegal State Exceptions 또는 Null Pointer를 전파할 수 없습니다.스택 위의 예외는 사용자의 기능과 관련이 있기 때문입니다.

IlgalArgument를 사용하는 경우 허용되는 프랙티스파라미터가 무효임을 선언하고 가능한 한 상세 정보를 제공하는 예외(String message)파라미터가 null인 반면 예외는 null이 아닌 것으로 판명된 경우 다음과 같이 합니다.

if( variable == null )
    throw new IllegalArgumentException("The object 'variable' cannot be null");

Null Pointer를 암묵적으로 사용할 이유가 거의 없습니다.예외입니다.Null Pointer예외는 null 참조(Like toString())에서 코드를 실행하려고 할 때 Java Virtual Machine에서 발생하는 예외입니다.

다음 사용자 전용 예외 발생null인수(유무)NullPointerException또는 커스텀 타입)을 사용하여null테스트의 신뢰성을 높입니다.이 자동 테스트는 Guava의 경우와 같이 리플렉션과 디폴트값 세트를 사용하여 실행할 수 있습니다.예를 들어 다음과 같습니다.NullPointerTester다음 메서드를 호출하려고 합니다.

Foo(String string, List<?> list) {
  checkArgument(string.length() > 0);
  // missing null check for list!
  this.string = string;
  this.list = list;
}

...두 가지 인수 목록:"", null그리고.null, ImmutableList.of()각 콜이 예상된 콜을 송신하는 것을 테스트합니다.NullPointerException이 실장에서는, 패스,null리스트가 생성되지 않음NullPointerException하지만, 그것은 우연한 결과를 낳는다.IllegalArgumentException왜냐면NullPointerTester디폴트 스트링을 사용하고 있다."".한다면NullPointerTester기대만 하다NullPointerException위해서null버그를 포착합니다.예상대로라면IllegalArgumentException놓치고 있어요

일반적으로 개발자는 Null Pointer를 던지면 안 됩니다.예외.이 예외는 코드가 값이 null인 변수를 참조 해제하려고 할 때 런타임에 의해 느려집니다.따라서 메서드가 null 값을 갖는 것이 아니라 null을 명시적으로 허용하지 않는 경우 Null Pointer를 발생시킵니다.예외입니다. IlgalArgument를 던져야 합니다.예외.

일부 수집에서는 다음과 같이 가정합니다.null를 사용하여 거부됩니다.NullPointerException보다는IllegalArgumentException예를 들어, 다음을 포함하는 세트를 비교한다면null거절하는 세트로null첫 번째 세트는containsAll반대편에서 그것을 잡아라NullPointerException--하지만 아닙니다.IllegalArgumentException(실현을 검토하고 있습니다)AbstractSet.equals.)

이러한 방식으로 체크되지 않은 예외를 사용하는 것은 반대이며, 다음을 포함하는 컬렉션을 비교하는 것은 반대라고 합리적으로 주장할 수 있습니다.null포함할 수 없는 컬렉션으로null실제로 예외를 발생시킬 가능성이 높은 버그이거나null안 좋은 생각인 것 같아요그럼에도 불구하고, 당신이 그렇게 말할 의향이 없다면equals그런 경우에 예외를 두어야 한다, 당신은 그것을 기억해야만 한다.NullPointerException('c' 이후를 제외하고 NPE 이전 IAE)는 필수입니다.")

NullPointerException현재 값이 다음과 같은 참조 변수를 사용하여 객체에 액세스하려고 할 때 던져지는 값null.

IllegalArgumentException메서드가 메서드에서 예상하는 형식과 다른 인수를 수신할 때 느려집니다.

다른 부정한 인수에서 Null 인수를 제외하려고 IAE에서 NullArgument라는 예외를 도출했습니다.예외.예외 메시지를 읽을 필요조차 없이 null 인수가 메서드에 전달된 것을 알고 메시지를 읽음으로써 어떤 인수가 null인지 알 수 있습니다.아직 NullArgument를 이해한다.IAE 핸들러의 경우는 예외입니다만, 로그에서는 그 차이를 금방 알 수 있습니다.

이분법...겹치지 않게 되어 있습니까?전체의 겹치지 않는 부분만이 이분법을 만들 수 있다.내가 보기엔:

throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));

시나리오에 따르면IllegalArgumentException최고의 선택입니다.왜냐하면null속성에 유효한 값이 아닙니다.

위의 두 예외 링크에서 정의되는 것은 IlgalArgument입니다.예외:메서드가 잘못된 인수 또는 부적절한 인수를 전달했음을 나타내기 위해 느려집니다.특수한 포인터예외:개체가 필요한 경우 응용 프로그램이 null을 사용하려고 할 때 느려집니다.

여기서 가장 큰 차이점은 IlgulateArgument입니다.예외는 메서드에 대한 인수가 유효한지 확인할 때 사용됩니다.특수한 포인터예외는 개체가 늘일 때 "사용"될 때마다 사용됩니다.

나는 그것이 두 사람을 시야에 넣는 데 도움이 되기를 바란다.

셋터나 나중에 멤버를 구할 때는 Ilgulate Argument를 사용하는 경향이 있습니다.예외.

메서드에서 지금 사용할(참조 해제) 것이라면 Null Pointer를 던집니다.사전에 예외를 인정합니다.저는 런타임에 맡기는 것보다 이것을 더 좋아합니다. 왜냐하면 저는 도움이 되는 메시지를 제공할 수 있기 때문입니다(런타임이 이것을 할 수 있는 것처럼 보이지만, 그것은 다른 날에 대한 호언장담입니다).

If I'm overriding a method, I use whatever the overridden method uses.

You should throw an IllegalArgumentException, as it will make it obvious to the programmer that he has done something invalid. Developers are so used to seeing NPE thrown by the VM, that any programmer would not immediately realize his error, and would start looking around randomly, or worse, blame your code for being 'buggy'.

In this case, IllegalArgumentException conveys clear information to the user using your API that the " should not be null". As other forum users pointed out you could use NPE if you want to as long as you convey the right information to the user using your API.

GaryF and tweakt dropped "Effective Java" (which I swear by) references which recommends using NPE. And looking at how other good APIs are constructed is the best way to see how to construct your API.

Another good example is to look at the Spring APIs. For example, org.springframework.beans.BeanUtils.instantiateClass(Constructor ctor, Object[] args) has a Assert.notNull(ctor, "Constructor must not be null") line. org.springframework.util.Assert.notNull(Object object, String message) method checks to see if the argument (object) passed in is null and if it is it throws a new IllegalArgumentException(message) which is then caught in the org.springframework.beans.BeanUtils.instantiateClass(...) method.

Ideally runtime exceptions should not be thrown. A checked exception(business exception) should be created for your scenario. Because if either of these exception is thrown and logged, it misguides the developer while going through the logs. Instead business exceptions do not create that panic and usually ignored while troubleshooting logs.

If you choose to throw a NPE and you are using the argument in your method, it might be redundant and expensive to explicitly check for a null. I think the VM already does that for you.

ReferenceURL : https://stackoverflow.com/questions/3881/illegalargumentexception-or-nullpointerexception-for-a-null-parameter