Message d’erreur de vérification nul comme «est nul» ou «était nul»

Étant donné que l’ Exception est levée en raison d’un échec de la vérification préalable, je pense que plutôt que de simplement énoncer un fait, vous devriez indiquer l’ exigence qui a été violée.

Autrement dit, au lieu de dire "username is null" , dites "username should not be null" .

Utilisation des bibliothèques pour les contrôles préalables

En guise d’astuce, vous pouvez utiliser l’une des nombreuses bibliothèques conçues pour faciliter les contrôles de précondition. De nombreux codes dans Guava utilisent com.google.common.base.Preconditions

Méthodes statiques simples à appeler au début de vos propres méthodes pour vérifier les arguments et l’état corrects. Cela permet des constructions telles que

  if (count <= 0) { throw new IllegalArgumentException("must be positive: " + count); } 

être remplacé par le plus compact

  checkArgument(count > 0, "must be positive: %s", count); 

Ce qui est plus directement pertinent ici, c'est qu'il a checkNotNull , ce qui vous permet d'écrire simplement:

  checkNotNull(username, "username should not be null"); 

Notez comment naturellement le code ci-dessus se lit, avec le message détaillé indiquant explicitement l’ exigence qui a été violée.

L'alternative consistant à énoncer des faits est plus délicate:

  // Awkward! checkArgument(count > 0, "is negative or zero: %s", count); checkNotNull(username, "username is null"); 

De plus, cela est aussi potentiellement moins utile, car le client est peut-être déjà au courant du fait, et l’exception ne l’aide pas à comprendre quelles sont les exigences réelles.

Sur IllegalArgumentException vs NullPointerException

Alors que votre code d'origine lève IllegalArgumentException sur null arguments null , IllegalArgumentException de Guava lève plutôt NullPointerException .

Ceci est conforme à la directive définie par l'API:

NullPointerException : les applications doivent émettre des instances de cette classe pour indiquer d'autres utilisations illégales de l'object null .

De plus, voici une citation tirée de Effective Java 2nd Edition: Article 60: Favorisez l’utilisation des exceptions standard :

On peut soutenir que toutes les invocations de méthode erronées se résument à un argument ou à un état illégal, mais d'autres exceptions sont couramment utilisées pour certains types d'arguments et d'états illégaux. Si un appelant transmet la valeur null à un paramètre pour lequel les valeurs null sont interdites, la convention stipule que NullPointerException être levée plutôt que IllegalArgumentException .

est nul , puisque l’argument est toujours nul ..

Cependant, pourquoi ne pas simplement lancer une exception NullPointerException sans message?

Je suggérerais de dire

  if (userName == null) { throw new IllegalArgumentException("username == null"); } 

comme cela est si fatal qu’un programmeur doit le regarder quand même. Faire référence à l’extrait de code incriminé dans le message d’exception est la chose la plus concise que je puisse imaginer.

Je serais enclin à écrire ceci:

 public User getUser(Ssortingng username) { if (username.length() == 0) { throw new IllegalArgumentException("username is empty"); } // ... } 

Cela tue deux oiseaux avec une pierre. Premièrement, il détecte le cas où le nom d’utilisateur est une chaîne vide, ce qui (par souci d’argument), je suppose, est une erreur. Deuxièmement, si le paramètre est null tenter de répartir l’appel de length nous donnera l’ NullPointerException .