J'essaie d'éviter les contrôles nuls exagérer, mais en même temps je veux faire un chèque nul à chaque fois qu'il doit rendre le code robuste. Mais parfois, je me sens comme ça commence à être tellement défensive puisque je ne mettons pas en œuvre API. Puis-je éviter certains contrôles nuls mais quand je commence les tests unitaires, il commence à attendre toujours des exceptions d'exécution. Quelle est la bonne approche, comment se sentir l'équilibre. Voici les notes que j'ai recueillis jusqu'à présent:
- éviter null contrôles inutiles dans des méthodes privées de la classe d'instance puisque les contrôles appropriés nuls sont effectués avant et la classe d'instance est responsable de cela, non pas chaque fonction
- procéder à des contrôles nuls dans les méthodes publiques et expliquer le comportement de la fonction dans le contrat pour l'usage public
- effectuer des vérifications dans le constructeur null
Permettez-moi de donner un exemple fictif où commence mon confusion:
Voici la fonction par défaut de l'interface:
default void someFunction() {
// instantiaded foo and filters
foo = processFoo(foo, filters);
// do some operations with foo
// null check if processFoo's contract returns null (description in the implementation)
}
La mise en oeuvre:
Foo processFoo(foo, filters) {
// Should I null check foo and filters?
// Operations with foo.someFields
// Operations with filters.someFields
return foo; // If I null check then I should return some exception or null to the caller function.
// If I don't null check just return received foo.
}
En règle générale, je ne vérifie pour nulls quand je suis dans le contrôle des appels, mais si mon code peut être appelé par quelqu'un d'autre, je fais appliquer des contrôles, puisque vous parlez d'une spécification API, vous pouvez vérifier l'entrée paramètres et lancer IllegalArgumentException.
Bien sûr, cela il est pas nécessaire, la plupart du temps, lorsque vous avez un NPE, il y a un bug quelque part sous-jacente, si vous n'êtes pas dans le contrôle total des appels, vous aurez certainement besoin d'un effort supplémentaire. (Expecially si votre API sera appelé fréquemment, vous besoin de quelque chose pour vous aider à tracer / identifier les modèles mauvais appel).
Lors de la conception d'une API, en dehors de l'architecture elle-même, vous devez vous concentrer également sur la maintenance / dépannage et la sécurité, expecially si l'API est exposée publiquement (ce qui signifie également désinfectante chaque paramètre).