IllegalArgumentException ou NullPointerException pour un paramètre nul? [fermé]

vous devez utiliser IllegalArgumentException (IAE), pas NullPointerException (NPE) pour les raisons suivantes:

tout d'abord, le NPE JavaDoc énumère explicitement les cas où la NPE est appropriée. Notez que tous sont lancés par le runtime quand null est utilisé de manière inappropriée. En revanche ,le IAE JavaDoc ne pouvait pas être plus clair: "jeté pour indiquer qu'une méthode a été passé un argument illégal ou inapproprié."Ouais, c'est vous!

Deuxièmement, quand vous voyez un NPE dans une trace de pile, que supposez-vous? Probablement que quelqu'un a déréférencé un null . Quand vous voyez des IAE, vous assumez l'appelant de la méthode en haut de la pile passé dans une valeur illégale. Encore une fois, la dernière hypothèse est vraie, la première est trompeuse.

Troisièmement, puisque IAE est clairement conçu pour valider les paramètres, vous devez supposer que le choix par défaut de l'exception, alors pourquoi choisir NPE à la place? Certainement pas pour un comportement différent -- est-ce que vous vous attendez vraiment à ce que le code appelant attrape les NPE séparément de IAE et fasse quelque chose de différent en conséquence? Êtes-vous essayer de communiquer un message d'erreur plus spécifique? Mais vous pouvez faire cela dans le texte du message d'exception de toute façon, comme vous le devriez pour tous les autres paramètres incorrects.

Quatrièmement, toutes les autres données de paramètre incorrectes seront IAE, alors pourquoi ne pas être cohérent? Pourquoi un null illégal est-il si spécial qu'il mérite une exception séparée de tous les autres types d'arguments illégaux?

enfin, j'accepte l'argument donné par d'autres réponses que certaines parties de L'API Java utilisent NPE de cette manière. Cependant, L'API Java est incompatible avec tout, des types d'exception aux conventions de nommage, donc je pense que copier simplement aveuglément (votre partie préférée) L'API Java N'est pas un bon argument pour surpasser ces autres considération.

la norme est de lancer la NullPointerException. L'infaillible "Java efficace" en parle brièvement au point 42 (première édition), au point 60 (deuxième édition), ou au point 72 (troisième édition) "favorise l'utilisation d'exceptions standard":

" sans doute, toute méthode erronée les invocations se résument à un illégales argument ou état illégal, mais autre les exceptions sont généralement utilisées pour certains types d'arguments et illégale Unis. Si un l'appelant passe null certains paramètres pour lesquels les valeurs nulles sont interdites, dicte la convention que Nullpointterexception soit jeté plutôt que de IllegalArgumentException."

j'étais tout à fait en faveur de lancer IllegalArgumentException pour les paramètres nuls, jusqu'à aujourd'hui, quand j'ai remarqué la méthode java.util.Objects.requireNonNull en Java 7. Avec cette méthode, au lieu de faire:

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

vous pouvez le faire:

Objects.requireNonNull(param);

et il lancera un NullPointerException si le paramètre que vous passez est null .

étant donné que cette méthode est juste bang au milieu de java.util je prends son existence pour être une jolie une forte indication que jeter NullPointerException est"la façon Java de faire les choses".

je pense que je suis décidé en tout cas.

notez que les arguments sur le débogage dur sont faux parce que vous pouvez bien sûr fournir un message à NullPointerException disant ce qui était nul et pourquoi il ne devrait pas être nul. Comme avec IllegalArgumentException .

un avantage supplémentaire de NullPointerException est que, dans le code de haute performance critique, vous pouvez dispense d'un contrôle explicite pour null (et d'un NullPointerException avec un message d'erreur amical), et fais juste confiance au NullPointerException que tu obtiendras automatiquement quand tu appelleras une méthode sur le paramètre null. Si vous appelez une méthode rapidement (i.e. fail fast), alors vous avez essentiellement le même effet, tout simplement pas aussi convivial pour le développeur. La plupart du temps, il est probablement préférable de vérifier explicitement et jeter avec un message utile pour indiquer quel paramètre était nul, mais il est agréable d'avoir le option de changer cela si la performance dicte sans rompre le contrat publié de la méthode/constructeur.

j'ai tendance à suivre la conception des bibliothèques JDK, en particulier les Collections et la concurrence (Joshua Bloch, Doug Lea, ces gars savent comment concevoir des API solides). Quoi qu'il en soit, de nombreux API dans le JDK lance pro-activement NullPointerException .

par exemple, le Javadoc pour Map.containsKey stipule:

@lance NullPointerException si la clé est nulle et cette carte ne permet pas les touches null (optionnel).

C'est parfaitement valable de lancer son propre NPE. La convention est d'inclure le nom du paramètre qui est nulle dans le message de l'exception.

Le patron dit:

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

quoi que vous fassiez, ne permettez pas à une mauvaise valeur d'être définie et de lancer une exception plus tard quand un autre code tente de l'utiliser. Cela fait du débogage un cauchemar. Vous devriez toujours suivre le principe" fail-fast".

a rejeté L'argument de Jason Cohen parce qu'il était bien présenté. Permettez-moi de le démembrer, étape par étape. ;- )

• Le NPE JavaDoc explicitement dit, "d'autres l'usage illicite de l'objet nul" . S'il était limité aux situations où le runtime rencontre un nul alors qu'il ne devrait pas, tous ces cas pourraient être définis de façon beaucoup plus succincte.

• ne Peut pas aidez - le si vous supposez la mauvaise chose, mais en supposant que l'encapsulation est appliquée correctement, vous ne devriez vraiment pas vous soucier ou remarquer si un null a été déréférencé de manière inappropriée par rapport à si une méthode a détecté un null inapproprié et tiré une exception.

• j'ai choisi NPE plus IAE pour de multiples raisons

  • il est plus spécifique sur la nature de l'illégal opération
  La logique
  • qui autorise par erreur les nulls tend à être très différente de la logique qui autorise par erreur les valeurs illégales. Par exemple, si Je valide des données entrées par un utilisateur, si j'obtiens une valeur qui est inacceptable, la source de cette erreur est avec l'utilisateur final de l'application. Si j'obtiens un null, c'est une erreur de programmeur.
  • les valeurs invalides peuvent causer des choses comme des débordements de pile, des erreurs de mémoire, des exceptions d'analyse, etc. En effet, la plupart des erreurs généralement présente, à un moment donné, comme une valeur non valide dans un appel de méthode. Pour cette raison, je considère l'EAI comme étant en fait le le plus général de toutes les exceptions sous RuntimeException.

• en fait, d'autres arguments invalides peuvent donner lieu à toutes sortes d'autres exceptions. UnknownHostException , FileNotFoundException , une variété d'erreur de syntaxe exceptions, IndexOutOfBoundsException , Échecs d'authentification, etc., etc.

en général, je pense que NPE est beaucoup calomnié parce que, traditionnellement, a été associé avec le code qui ne suit pas le fail fast principle . Cela, en plus de l'incapacité du JDK à remplir les NPE avec une chaîne de messages, a vraiment créé un fort sentiment négatif qui n'est pas bien fondé. En effet, la différence entre NPE et IAE à partir d'un runtime point de vue est strictement le nom. De ce point de vue, plus vous êtes précis avec le nom, plus vous donnez de clarté à l'appelant.

c'est une question de style "Guerre Sainte". En d'autres termes, les deux solutions sont bonnes, mais les gens ont leurs préférences dont ils défendrai jusqu'à la mort.

si c'est une méthode setter et que null lui est passé, je pense qu'il serait plus logique de jeter un IllegalArgumentException . Un NullPointerException semble avoir plus de sens dans le cas où vous tentez d'utiliser réellement le null .

Donc, si vous l'utilisez, et c'est null , NullPointer . Si c'est passé et que c'est null , IllegalArgument .

Apache Commons Lang a un NullArgumentException qui fait un certain nombre des choses discutées ici: il étend IllegalArgumentException et son seul constructeur prend le nom de l'argument qui aurait dû être non-null.

alors que je pense que lancer quelque chose comme une NullArgumentException ou IllegalArgumentException décrit plus précisément les circonstances exceptionnelles, mes collègues et moi avons choisi de nous en remettre aux conseils de Bloch sur le sujet.

est tout à fait d'accord avec ce qui est dit. L'échec précoce, échec rapide. Très bon mantra D'Exception.

la question de l'Exception à jeter est surtout une question de goût personnel. Dans mon esprit IllegalArgumentException semble plus spécifique que l'utilisation d'un NPE car il me dit que le problème était avec un argument que j'ai passé à la méthode et pas avec une valeur qui peut avoir été générée tout en exécutant la méthode.

Mes 2 Cents

la pratique acceptée si d'utiliser le IllegalArgumentException( message de chaîne de caractères) pour déclarer qu'un paramètre est invalide et donner autant de détails que possible... Donc, pour dire qu'un paramètre a été trouvé nul alors que l'exception non nul, vous feriez quelque chose comme ceci:

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

vous n'avez pratiquement aucune raison d'utiliser implicitement la"NullPointerException". La NullPointerException est une exception lancée par la machine virtuelle Java lorsque vous essayez d'exécuter du code sur référence nulle (comme toString() ).

en fait, la question de jeter IllegalArgumentException ou NullPointerException n'est à mon humble avis qu'une "guerre sainte" pour une minorité avec une compréhension incomparable de la gestion des exceptions en Java. En général, les règles sont simples, et comme suit:

"151930920 argument de" violations de contrainte doit être indiqué aussi vite que possible (-> rapide échec), afin d'éviter illégale états qui sont beaucoup plus difficiles à déboguer
• dans le cas d'une null pointer pour quelque raison que ce soit, jeter NullPointerException
• dans le cas d'un array/collection index illégal, lancer ArrayIndexOutOfBounds
• dans le cas d'un tableau négatif/taille de la collection, jeter NegativeArraySizeException
• dans le cas d'un argument illégal qui n'est pas couvert par ce qui précède, et pour lequel vous n'avez pas un autre type d'exception plus spécifique, jeter IllegalArgumentException comme un wastebasket
• d'autre part, en cas de violation d'une contrainte dans un domaine qui ne pourrait pas être évitée par fast fail pour une raison valable, catch et rethrow comme IllegalStateException ou une exception contrôlée plus spécifique. Ne laissez jamais passer la NullPointerException originale, ArrayIndexOutOfBounds, etc dans ce cas!

Il ya au moins trois très bonnes raisons contre le cas de la cartographie de toutes sortes de violations de contrainte d'argument à L'Illégalargumentexception, avec le troisième étant probablement si sévère que de marquer la pratique de mauvais style:

(1) un programmeur ne peut pas présumer en toute sécurité que tous les cas de violation des contraintes d'argument aboutissent à une interception illégale, parce que la grande majorité des classes standards utilisent cette exception plutôt comme une corbeille à papier s'il n'y a pas de type d'exception plus spécifique disponible. Essayer de cartographier tous les cas de violation des contraintes d'argument à IllegalArgumentException dans votre API ne conduit qu'au programmeur frustration en utilisant vos classes, car les bibliothèques standards suivent généralement des règles différentes qui violent les vôtres, et la plupart des utilisateurs de votre API les utiliseront aussi!

(2) cartographier les exceptions aboutit en fait à un autre type d'anomalie, causée par un héritage unique: toutes les exceptions Java sont des classes, et ne prennent donc en charge qu'un héritage unique. Par conséquent, il n'y a aucun moyen de créer une exception qui est vraiment dire à la fois NullPointerException et un IllegalArgumentException, comme sous-classes ne peuvent hériter de l'un ou l'autre. Lancer une IllegalArgumentException en cas d'argument null rend donc plus difficile pour les utilisateurs de L'API de faire la distinction entre les problèmes chaque fois qu'un programme essaie de corriger programmatiquement le problème, par exemple en introduisant des valeurs par défaut dans une répétition d'appel!

(3) la cartographie crée en fait le risque de masquage de bogue: afin de cartographier les violations des contraintes d'argument en IllegalArgumentException, vous aurez besoin de coder un try-catch externe dans chaque méthode qui a des arguments limités. Cependant, il est hors de question de simplement attraper RuntimeException dans ce bloc de capture, car cela risque de cartographier les exceptions RuntimeException documentées lancées par des méthodes libery utilisées dans le vôtre dans IllegalArgumentException, même si elles ne sont pas causées par des violations des contraintes d'argument. Donc vous devez être très précis, mais même cet effort ne vous protège pas du cas où vous accidentellement mapper une exception d'exécution non documentée d'une autre API (c.-à-d. un bogue) dans une Illégalargumentexception de votre API. Même la cartographie la plus soigneuse risque donc de masquer les erreurs de programmation d'autres documentaristes comme des violations de contraintes d'arguments des utilisateurs de votre méthode, ce qui est simplement un comportement hillareous!

D'un autre côté, avec la pratique courante, les règles restent simples, et les causes d'exception restent non masquées et spécifiques. Pour la méthode de l'appelant, les règles sont facile ainsi: - si vous rencontrez une exception documentée d'exécution de n'importe quelle sorte parce que vous avez passé une valeur illégale, soit répéter l'appel avec un défaut (pour ces exceptions spécifiques sont nécessaires), ou corriger votre code - si d'un autre côté vous Encounter une exception d'exécution qui n'est pas documentée pour se produire pour un ensemble donné d'arguments, file un rapport de bogue aux responsables de la méthode pour s'assurer que leur code ou leur documentation est corrigé.

en général, un développeur devrait jamais lancer une NullPointerException. Cette exception est lancée par l'exécution lorsque le code tente de déréférencer une variable dont la valeur est nulle. Par conséquent, si votre méthode veut explicitement désactiver null, par opposition à ce qui arrive juste pour avoir une valeur nulle soulever une NullPointerException, vous devez lancer une IllegalArgumentException.

lancer une exception qui est exclusive à null arguments (si NullPointerException ou un type personnalisé) rend automatique null test plus fiable. Ce test automatisé peut être fait avec réflexion et un ensemble de valeurs par défaut, comme dans Goyave NullPointerTester . Par exemple, NullPointerTester tenterait d'appeler la méthode suivante...

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

...avec deux listes d'arguments: "", null et null, ImmutableList.of() . Il vérifierait que chacun de ces appels jette le NullPointerException attendu . Pour cette mise en œuvre, passer une liste null ne pas produire NullPointerException . Il arrive, cependant, de produire un IllegalArgumentException parce que NullPointerTester utilise une chaîne de caractères par défaut de "" . Si NullPointerTester s'attend à seulement NullPointerException pour les valeurs null , il attrape le bug. S'il attend IllegalArgumentException , il le rate.

comme une question subjective, cela devrait être fermé, mais comme il est toujours ouvert:

Cela fait partie de la politique interne utilisée à mon ancien lieu de travail et cela a très bien fonctionné. C'est de mémoire, donc je ne me souviens pas de la formulation exacte. Il est intéressant de noter qu'ils n'ont pas utilisé d'exceptions vérifiées, mais cela dépasse la portée de la question. Les exceptions non vérifiées qu'ils ont utilisées se répartissaient en trois catégories principales.

NullPointerException: ne pas jeter intentionnellement. Les NPE ne doivent être lancés que par la VM lorsque la référence est nulle. Tout l'effort possible doit être fait pour s'assurer que ce ne sont jamais jetés. @Nullable et @NotNull devraient être utilisés conjointement avec les outils d'analyse de code pour trouver ces erreurs.

IllegalArgumentException: lancé lorsqu'un argument à une fonction n'est pas conforme à la documentation publique, de sorte que l'erreur peut être identifiée et décrite en termes de les arguments passés. La situation de L'OP relèverait de cette catégorie.

IllegalStateException: lancé lorsqu'une fonction est appelée et que ses arguments sont soit inattendus au moment où ils sont passés, soit incompatibles avec l'état de l'objet dont la méthode est membre.

par exemple, il y avait deux versions internes de L'IndexOutOfBoundsException utilisées dans les choses qui avaient une longueur. Une sous-classe de IllegalStateException, utilisée si l'index était plus grand que la longueur. L'autre est une sous-classe D'ArgumentException illégale, utilisée si l'index est négatif. C'est parce que vous pouvez ajouter d'autres éléments à l'objet et l'argument serait valable, alors qu'un nombre négatif n'est jamais valide.

Comme je l'ai dit, ce système fonctionne vraiment bien, et il a fallu quelqu'un pour expliquer pourquoi la distinction est-il: "en Fonction du type d'erreur, il est assez simple pour vous de comprendre quoi faire. Même si vous ne pouvez pas vraiment comprendre vous pouvez trouver où trouver cette erreur et créer des informations de débogage supplémentaires."

NullPointerException: gérer le cas nul ou mettre dans une affirmation de sorte que le NPE n'est pas lancé. Si vous mettez dans l'affirmation est juste l'un des deux autres types. Si possible, continuez le débogage comme si l'affirmation était là en premier lieu.

IllegalArgumentException: vous avez quelque chose de mal à votre site d'appel. Si les valeurs transmises sont d'une autre fonction, savoir pourquoi vous recevez une valeur incorrecte. Si vous passez dans l'un de vos arguments propager l'erreur vérifie la pile d'appels jusqu'à ce que vous trouviez la fonction qui ne retourne pas ce que vous attendez.

IllegalStateException: vous n'avez pas appelé vos fonctions dans le bon ordre. Si vous utilisez l'un de vos arguments, vérifiez-les et lancez une exception IllegalArgumentException décrivant le problème. Vous pouvez ensuite propager les joues vers le haut contre la pile jusqu'à ce que vous trouver le problème.

quoi qu'il en soit, son point était que vous ne pouvez copier les instructions illégales D'Argumentqu'en haut de la pile. Il n'y a aucun moyen pour vous de propager les exceptions IllegalStateExceptions ou NullPointerExceptions dans la pile parce qu'elles ont quelque chose à voir avec votre fonction.

je voulais distinguer les arguments Nuls des autres arguments illégaux, donc j'ai dérivé une exception de IAE named NullArgumentException. Sans même avoir besoin de lire le message d'exception, je sais qu'un argument null a été passé dans une méthode et en lisant le message, je découvre quel argument était null. J'attrape toujours la NullArgumentException avec un handler IAE, mais dans mes logs est où je peux voir la différence rapidement.

la dichotomie... Ne se chevauchent-ils pas? Seules les parties ne se chevauchant pas d'un tout peuvent faire une dichotomie. Comme je le vois:

throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));

certaines collections supposent que null est rejeté en utilisant NullPointerException plutôt que IllegalArgumentException . Par exemple, si vous comparez un ensemble contenant null à un ensemble qui rejette null , le premier s'appel containsAll sur l'autre, et de rattraper son NullPointerException , mais pas IllegalArgumentException . (Je regarde la mise en œuvre de AbstractSet.equals .)

vous pourriez raisonnablement soutenir que l'utilisation d'exceptions non vérifiées de cette façon est un anti-modèle, que comparer des collections qui contiennent null à des collections qui ne peuvent pas contenir null est un bug probable que vraiment devrait produire une exception, ou que mettre null dans une collection est une mauvaise idée. Néanmoins, sauf si vous êtes prêt à dire que equals devrait jeter une exception dans un tel cas, vous êtes coincé en se rappelant que NullPointerException est nécessaire dans certaines circonstances mais pas dans d'autres. (') Avant NPE, sauf après "c"...")

NullPointerException lancée en essayant d'accéder à un objet avec une variable de référence dont la valeur actuelle est nulle

IllegalArgumentException lancée quand une méthode reçoit un argument formaté différemment que la méthode attend

selon votre scénario, IllegalArgumentException est le meilleur choix, parce que null n'est pas une valeur valide pour votre propriété.

idéalement, les exceptions à l'exécution ne devraient pas être lancées. Une exception cochée (business exception) doit être créée pour votre scénario. Parce que si l'une ou l'autre de ces exceptions est lancée et enregistrée, elle guide mal le développeur en parcourant les journaux. Au lieu de cela, les exceptions d'affaires ne créent pas cette panique et généralement ignorées pendant les journaux de dépannage.

les définitions des liens aux deux exceptions ci-dessus sont les suivantes: IllegalArgumentException: lancé pour indiquer qu'une méthode a été passé un argument illégal ou inapproprié. NullPointerException: lancé lorsqu'une application tente d'utiliser null dans un cas où un objet est requis.

la grande différence ici est que la IllegalArgumentException est censée être utilisée pour vérifier qu'un argument d'une méthode est valide. NullPointerException est censé être utilisé chaque fois qu'un objet d'être "utilisé" quand il est nul.

j'espère que cela aide à mettre les deux en perspective.

si c'est un" setter", ou quelque part que je vais faire utiliser plus tard par un membre, j'ai tendance à utiliser IllegalArgumentException.

si c'est quelque chose que je vais utiliser (dereference) en ce moment dans la méthode, je lance une NullPointerException de manière proactive. J'aime mieux cela que de laisser le runtime le faire, parce que je peux fournir un message utile (il semble que le runtime pourrait le faire aussi, mais c'est une exclamation pour un autre jour).

si j'annule une méthode, j'utilise quelle que soit la méthode substituée utilise.

vous devez lancer un ArgumentException illégale, car il sera évident pour le programmeur qu'il a fait quelque chose d'invalide. Les développeurs sont tellement habitués à voir NPE lancé par la VM, que n'importe quel programmeur ne réaliserait pas immédiatement son erreur, et commencerait à regarder autour au hasard, ou pire, blâmer votre code pour être 'buggy'.

dans ce cas, IllegalArgumentException transmet des informations claires à l'utilisateur en utilisant votre API que le"ne doit pas être null". Comme d'autres utilisateurs du forum l'ont souligné, vous pouvez utiliser NPE si vous le souhaitez à condition de transmettre les bonnes informations à l'utilisateur en utilisant votre API.

GaryF et tweakt abandonné "Effective Java" (je jure) par les références qui recommande l'utilisation des NPE. Et regarder comment d'Autres Bons API sont construits est la meilleure façon de voir comment construire votre API.

un autre bon exemple est de regarder les API de printemps. Par exemple, org.springframework.haricot.BeanUtils.instantiateClass (Constructor ctor, Object[] args) a une assertion.notNull(ctor, "Constructeur ne doit pas être null"). org.springframework.util.Affirmer.la méthode notNull(Object object, String message) vérifie si l'argument (object) transmis est null et si c'est le cas, lance une nouvelle IllegalArgumentException(message) qui est alors capturée dans le org.springframework.haricot.BeanUtils.instantiateClass(...) méthode.

si vous choisissez de lancer un NPE et que vous utilisez l'argument dans votre méthode, il peut être redondant et coûteux de vérifier explicitement un null. Je pense que la VM le fait déjà pour toi.