Je vois souvent Java SourceCode où une valeur nulle comme valeur pour une méthode ou un constructeur n'est pas autorisée. Une implémentation typique de cela ressemble à Je ne vois pas de sens pour moi-même dans ce tout, car si je tente d'appeler une méthode sur un nullpointer, le nullpointerexception est jeté de toute façon. Je verrais un sens si cette méthode lancerait une erreur illégale ou une autre exception sur mesure. Est-ce que quelqu'un peut-il nettoyer, pourquoi ce chèque semble avoir du sens (comme je le vois très souvent, je suppose que cela doit être sentiment derrière cela), ou pourquoi il s'agit d'un non-sens complet
9 Réponses :
Cela dépend de qui est responsable de la récupération de cette situation. Si c'est l'appelant, lancez une NPE. Si c'est la méthode appelée, testez pour edit: Ne jetez pas une NPE explicitement, mais laissez-la simplement bouillir. Désolé pour le libellé vague. null et faire tout ce qui est nécessaire pour résoudre la situation.
Mais dans le cas l'exemple de l'OP a donné, il est clair que la méthode elle-même ne se recouvre pas de l'exception ...
Vrai, mais j'ai pris cela seulement comme une MWe, pas comme du vrai code.
Lancer une exception décochée est une mauvaise pratique de programmation ...
Les exceptions cochées @Alex doivent être levées lorsqu'il y a une attente raisonnable que l'appelant puisse le gérer en quelque sorte, etc. Certainement pas à cause des erreurs de programmation. Ou pensez-vous vraiment que nous devrions faire arrayoutofboundsException vérifié aussi?
@VOO: Les exceptions non cochées représentent généralement des erreurs dans votre code. Par exemple, l'arrayoutofboundsException signifie que vous accédez à la matrice de mauvaise manière et que cette "erreur de programme" doit être corrigée. L'exécution normale d'un programme ne doit pas normalement rencontrer des exceptions non vérifiées ...
@Voo: docs.oracle.com/javase/Tutorial/essential/Exceptions / ... -> "D'une manière générale, ne jetez pas une exception à la piste ou crée une sous-classe de RunTimeException simplement parce que vous ne voulez pas être dérangé par la spécification des exceptions que vos méthodes peuvent lancer."
@Alex et donner un paramètre illégal à une exception n'est pas une erreur de programmation?
@Voo oui c'est! Mais la meilleure pratique et le bon sens indique que les méthodes doivent lancer des exceptions escrochées (définir une exception personnalisée qui encapsulent votre programme de mauvaises cas d'utilisation) et ces exceptions doivent être traitées par l'appelant. Une exception non cochée ne sera visible qu'au runtime et qu'il peut causer beaucoup de douleur après des déploiements. Ce n'est pas le cas avec des cas de test bien sûr ...
@ALEX, mais jetant une exception vérifiée pour les intrants illégales rendrait le code plutôt difficile à manier et ne devrait pas arriver dans un code valide (et j'espère que quelqu'un dirigerait le code au moins une fois avant d'être déployé!). Et il y a la priorité pour cela dans la bibliothèque standard, comme hashtable.put par exemple. Il me semble que cela conduirait à des modèles tels que Catch (Someexception E) {// ne peut jamais arriver! } que je n'aime pas non plus.
@VOO: Il y a des situations où jeterais décoché est le seul moyen d'y aller ... Ce n'est pas l'un d'entre eux, sinon ils ne doivent pas être utilisés à moins que vous n'ayez des interfaces bien définies, avec des contrats forts, comme l'interface de la carte. Vous ne pouvez pas créer de code qui lance des exceptions d'exécution partout ... il est juste satimentable ...
@Alex Eh bien, je suppose que la fonction est clairement documentée comme objet quelqueObject hashtable.put le gère. Faire quelque chose qu'une exception vérifiée ne doit jamais être remplacée pour une bonne documentation, ces deux choses sont là pour différentes raisons.
Le code que vous avez affiché n'a absolument aucun sens du tout. Il ressemble à un cas fort de Programmation de Cult de Cargo . Très probablement, quelqu'un a mis en œuvre un test utile pour vérifier les pré-conditions une fois et quelqu'un d'autre a adapté le test pour ressembler à ceci.
Non, cela n'a pas beaucoup de sens que cela se tient, mais seulement parce que jetant une NPE n'ajoute aucune information utile.
Vous pouvez rendre l'erreur plus agréable en lançant (par exemple) une exception illégale: mais qui n'ajoute pas beaucoup de valeur, non plus que d'être spécifique à propos de ce qui est NULL (qui peut être utile dans des méthodes plus complexes)
Et l'exception possible doit être déclarée dans la clause et documentées.
Bien sûr, vous voulez vérifier NULL. Ceci est une condition préalable à votre méthode, une partie de son contrat avec des clients. Si votre méthode ne peut accepter l'entrée NULL, vous devez appliquer cela.
Le choix de l'exception pourrait être meilleur. Je vais habituellement avec un Si c'est la brièveté de la méthode qui vous dérange, je dois dire que je suis d'accord. Pas de nouvelles informations là-bas. illegalargumentException .
Je ne crois pas IllegalArgumentException est meilleur choix. NPE est plus spécifique. Vous pouvez également consulter l'article 60 de Java efficace à ce sujet.
Je vais donner un look, mais je ne sais pas si je suis d'accord. Le message dans l'IAE peut le rendre assez clair. Il peut également signaler d'autres conditions (par exemple une chaîne qui ne peut être ni vide ni null). Votre interprétation est très étroite, mais correcte pour ce problème.
Je pense que ce type de chèque a du sens si une méthode traite qui prend beaucoup de temps ou est difficile à annuler avant de déclencher la NPE. Dans l'exemple donné, je ne pense pas que cela ait le sens réel.
D'autre part: Utiliser affirmer ou jeter une exception plus spécifique comme illégalargumentException pourrait avoir plus de sens.
en C # existe une erreur d'argumentation. Cette exception prend le nom de l'argument dans le constructeur. Donc, l'appelant pouvait voir, quel argument est peut-être illicity null. L'illégalargumentexception est presque l'équivalent Java à cela.
La situation que vous décrivez peut être utile sous l'une des hypothèses suivantes:
1.) Si vous devez effectuer des opérations coûteuses ou modifiées, un état global avant l'exécution 2.) Si ToeObject.Amethodcall () Vous pouvez empêcher le code de restauration et le gaspillage de cycles d'exécution.
ToNOObject est stocké dans une structure de données, vous pouvez créer un piège possible si à un moment donné, les données sont extraites de la structure de données. Je pense que je me souviens de quelques classes dans le cadre de collecte Java, qui jettent plutôt une NPE que de permettre à une null dans la structure de stockage.
Un exemple des collections Java: anciennes versions d'un ESTRESET vide autorisé NULL Pour ajouter, seulement pour lancer une NPE lorsqu'un deuxième élément devait être ajouté. La version actuelle de arbreset.add vérifie explicitement pour null .
Il y a un coin d'angle où quelque chose comme ça aurait un sens. Si vous n'utilisez pas immédiatement ToOObject Shel-circuit, le boîtier d'erreur correspond au début de la fonction peut être utile.
+1 Un chèque et un lancer explicite peut être utile. Pensez à échouer rapidement, échouez tôt.
Personnellement, la raison pour laquelle je ne jetterais jamais une nullpoinpoinpointException dans le cadre d'une méthode de l'API publique est que cela rend la distinction beaucoup plus difficile pour le programmeur de distinguer une erreur de programmation de leur côté et un bogue dans mon code (c'est-à-dire que j'ai laissez délibérément jeter le NPE ou non?).
Lancer une exception différente rend l'intention beaucoup plus claire et aide également le programmeur à découvrir ce qui ne va pas plus facilement. Je vais donc avec Si c'est une méthode interne? J'utiliserais des assertions ou je le laissais tomber. Aucun sens pour jeter explicitement une NPE imo. illegalargumentException là-bas.
Ceci est inutile si le bon comportement est le pointeur NULL (en fait, c'est pire car le chèque prend une petite quantité de temps).
Dupliquer possible: Stackoverflow.com/Questtions/32280/Passing- NULL-TO-A-METHODE Je préfère les assertions pour la vérification de la bonté des paramètres, tout comme des conditions préalables sont utilisées dans ADA.
Les chèques nuls explicites sont aussi bon marché que des chèques nuls implicites après Jit'ing, donc je ne m'inquiéterais pas pour la performance ici.
Je dirais que c'est la mauvaise exception d'être jetée. Si quelque chose, vous devriez lancer un
IllegalargumentExceptionLorsque vous exécutez la condition préalable à la condition d'une méthode avant tout est terminée. C'est vraiment ce que vous voulez faire. Vous avez raison, Cette exception est la fausse exception , mais cela ne signifie pas que vous ne devriez pas effectuer le chèque ou jeter la bonne exception .