12
votes

Pourquoi instancier les variables avec une valeur null

Dans de nombreux éléments de code exemple, je vois des variables instaciées avec des valeurs null et attribués ultérieurement des valeurs plus significatives.

Je me demandais simplement pourquoi les gens peuvent faire cela. Je suppose que les blocs d'essais d'essais peuvent bien venir dans cette situation, mais je vois aussi des variables instanciées des valeurs nulelles à l'intérieur d'un bloc d'essai.

(Je suis sûr que c'est une question assez linguistique agnostique, mais simplement pour référence, je programme presque entièrement en Java)

Toutes les idées appréciées!


4 commentaires

Je pense que c'est une question valable. +1 pour équilibrer le bowvote.


C'est ce qui se passe lorsque le Downvoter ne laisse pas de commentaire.


Simplement parce que dans beaucoup de cas, sinon le code ne compilera tout simplement pas. Maintenant, pourquoi les spécifications Java Mandates sont une autre question mais +1 à Mforster qui a souligné le message d'erreur compilateur exact. Notez que vous n'avez même pas besoin de compiler un fichier valide .java pour obtenir ce message d'erreur. Par exemple: Intellij Idea (incroyable Java IDE) vous avertira de votre erreur en temps réel, même sur une AST partielle (c'est-à-dire: un fichier partiel .java que vous ne pouviez pas vous compiler car c'est incomplet).


@SeanpatrickFloyd lol, +1 Pour équilibrer le Downvote ... Je déteste les personnes avec une réputation plus élevée sur lesquelles tous les mauvaises gars pauvres.


3 Réponses :


13
votes

Le compilateur Java détecte dans certains cas si une variable n'a pas été initialisée dans toutes les flux de contrôle possibles et imprime une erreur. Pour éviter ces messages d'erreur, il est nécessaire d'initialiser explicitement la variable.

Par exemple, dans ce cas: xxx

Le compilateur donnerait à ce message d'erreur: "La variable locale Le résultat n'a peut-être pas été initialisé ".

Voici ce que Spécification de la langue Java dit:

Chaque variable locale (§14.4) et chaque finale vide (§4.5.4) champ (§8.3.1.2) doit avoir une valeur définitivement attribuée lorsque tout accès de sa valeur survient. Un compilateur Java doit porter une analyse de flux conservateur spécifique pour vous assurer que Pour chaque accès d'une variable locale ou d'un champ final vierge F, F est définitivement attribué avant l'accès; sinon un Une erreur de compilation doit se produire.

Notez que (contrairement aux champs!) Les variables locales ne sont pas automatiquement initialisées à null .


5 commentaires

Il émet une erreur pour vous aider à éviter les exceptions d'exécution! Je ne dirais pas que c'est nécessaire. En fait, je dirais que c'est très pauvre de ne pas vous assurer que chaque flux de contrôle avait un objet valide.


Je faisais référence au message d'erreur par le compilateur. Je pense que ceux-ci sont même mandatés par la spécification de la langue.


Est-ce que quelqu'un d'autre pense qu'il est étrange que le quakeatoat a posé cette question et des bléties ont commenté une réponse?


@Mikeg Mon commentaire n'a pas fait référence à sa réponse modifiée, mais à l'original. En disant "Attribuez-le à NULL afin de ne pas lancer cette erreur" au lieu de la façon dont il se lit maintenant "initialiser explicitement la variable" est semblable à dire "il suffit de mettre des blocs d'essai vides / attrayez-la" au lieu de "gérer les exceptions avec essayer / blocs de capture. "


Désolé pour la confusion. J'ai édité la réponse pour clarifier ce que je voulais dire.



4
votes

Personnellement, je n'aime pas les champs de membre qui prend une valeur dans le constructeur. Il y avait un moment où je pensais que c'était juste agréable d'être explicite, mais il y a une différence de bytecode entre l'affectation d'un champ à null explicitement ou que le champ prenant la valeur par défaut.

Même pour les champs qui commencent comme null (et Ensuite, acquérir une valeur un jour après l'initialisation) Je ne suis pas un grand fan d'eux. Il met généralement en évidence simplement le malentendu du développeur qui l'a fait.

La pertinence try-capte est dans des cas comme celui-ci: xxx

car r est une variable locale ici, il a besoin d'une valeur avant de pouvoir être utilisée, de sorte que l'affectation est nécessaire. Si l'affectation à NULL arrive dans le même chemin de code que sa réaffectation et / ou une utilisation ultérieure, il s'agit probablement d'une redondance trompeuse.


2 commentaires

Je ne produis généralement que du code utilisant des objets immuables afin que les champs membres qui prennent une valeur dans le constructeur sont généralement tous marqués comme final dans mon code, ce qui rend le point un peu discutable: dans ce cas, vous ne pouvez tout simplement pas l'affecter NULL Tout d'abord, changez-le dans le CTOR.


@Webinator: Certainement. Un bel effet secondaire des membres finaux.



0
votes

Oui, pensé à cette question plusieurs fois.

Pour l'instant, je donne généralement une valeur initiale null pour un objet et une valeur sans danger pour le type simple. La raison, parfois, vous ne savez pas que le JRE donne la valeur initiale à la variable. Et parfois, vous devez juger que la variable est NULL, vous oubliez peut-être l'initial. Certains bugs sont faciles à trouver, si vous donnent des variables une valeur initiale.


0 commentaires