java - Devrais-je supprimer la possibilité de nullité des méthodes remplacées qui ne sont pas annotées avec nullable dans une classe héritée
android kotlin (6)
Ils ne sont pas spécifiés comme annotations Nullable dans le code Java.
Si c'est vrai, sachez que vous risquez de
NullPointerException
une
NullPointerException
si elle n'est pas spécifiée comme annotation Nullable dans le code Java et d'attribuer une valeur NULL.
supprimez donc la nullabilité de la méthode remplacée si elle n'est pas spécifiée comme annotation nullable dans le code Java.
Pour plus de détails, lisez aussi kotlinlang.org
Android 3.5.1
J'utilisais WebView et j'ai remarqué que lorsque je redéfinis certaines méthodes, tous les paramètres sont des types nullables:
webview.webViewClient = object : WebViewClient() { override fun shouldOverrideUrlLoading(view: WebView?, request: WebResourceRequest?): Boolean { return super.shouldOverrideUrlLoading(view, request) } }
Ce qui signifie que je dois utiliser l'opérateur de
safe call
pour les utiliser.
Cependant, lorsque j'ai consulté la classe
WebViewClient
laquelle j'ai
WebViewClient
la méthode, elles ne sont pas spécifiées comme annotations
nullable
dans le code Java.
public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) { return shouldOverrideUrlLoading(view, request.getUrl().toString()); }
Il me reste donc à penser que je supprime la nullité de la méthode remplacée ou la conserve?
Au niveau de la langue, ceci peut être généralisé:
Pour une interopérabilité correcte de Java, le code Kotlin doit refléter les annotations du code Java.
Le linter se plaint seulement de l'absence d'annotations dans l'autre sens, pour l'interopérabilité de Kotlin.
Voir cet article récent sur Comment écrire du code Kotlin compatible avec Java?
Contrairement à Kotlin, les objets Java peuvent accepter par défaut des valeurs nulles
L' annotation @Nullable est uniquement utilisée pour des opérations telles que les analyseurs de code (par exemple, si le paramètre @Nullable n'est pas géré dans la méthode, il affichera un avertissement).
L' annotation @NonNull est utilisée pour spécifier que la valeur reçue ne peut pas / ne sera pas nulle
if(@NonNull){ can omit ? check }else if(@Nullable){ Mandatory to put ? check }else(No annotation){ Not mandatory but put on safer side . Passing null from Java into Kotlin fun without ? will lead to NPE if(putting ? check){ java equivalent Kotlin param (@Nullable Webview view) } else{ java equivalent Kotlin param (@NonNull Webview view) } }
La référence nulle est une exception assez évidente pour tout le monde maintenant, car tout a commencé avec le développement natif en C / C ++. La référence aux objets en mémoire peut être manquante ou nettoyée pour différentes raisons. Java a été conçu à la manière de ces langues natives , qui supposent des pointeurs nuls partout.
La gestion de tous les états mutables s'amuse avec des milliers de microservices.
Cela cause beaucoup de solution de contournement pour la référence Nullable.
- Objets
Optional
- Mock of
Null Object
-
Wrappers
autour de références -
Annotations
, etc. Et tout cela pour éviter de changer d'état d'objet alloué quelque part.
Enfin, Kotlin n'est pas le premier ici.
Scala, aux états immuables, avait une excellente expérience d'utilisation et d'application.
Donc, pour répondre à cette question et résumer,
Java a été conçu de cette manière à partir de son parent C ++, et vous devez vous attendre à des valeurs nulles partout.
Nous
@Nullable
toujours la référence pour null, même si elle n'est pas annotée
@Nullable
, pour cette raison.
Et de la même manière, Kotlin gère l'utilisation de Java. C'est pourquoi vous devez gérer les valeurs NULL dans les méthodes remplacées.
La source de ce problème provient de l'
interopérabilité entre Java et Kotlin
.
Il existe des différences de niveau de langage de base entre
Java
et
Kotlin
qui posent des problèmes d'interopérabilité.
Android Studio fournit des contrôles
Lint
pour les avertir, tels que
Unknown Nullness
.
(
reference
)
En examinant les détails de
Unknown nullness
Lint check sur
android.com
, nous constatons que:
Pour améliorer le code de référencement de
Kotlin, pensez à ajouter ici des informations de nullité explicites avec
@NonNullou
@Nullable.
et sur developer.android.com :
Si vous utilisez
Kotlinpour référencer un membre avec un nom non annoté défini dans une classe
Java( par exemple, une
String), le compilateur ne sait pas si la
Stringmappée sur une
Stringou sur une
String?à
Kotlin. Cette ambiguïté est représentée via un type de plateforme ,
String!.
et sur kotlinlang.org :
Toute référence en
Javapeut être nulle , ce qui rend les exigences de sécurité stricte pour
Kotlinirréalisables pour les objets provenant de
Java. Les types de déclarations
Javasont traités spécialement dans
Kotlinet sont appelés types de plate-forme .
Par conséquent, lorsque nous redéfinissons une méthode
Java
pour que ses arguments ne soient pas annotés avec des annotations de nullité, l'EDI ajoute un signe nullable (
?
) Pour les arguments de la classe
Kotlin
.
Cela
évite de lancer
NullPointerException
lorsque la méthode est appelée en
Java
en transmettant une valeur
null
pour l'un des arguments.
webview.webViewClient = object : WebViewClient() { override fun shouldOverrideUrlLoading( view: WebView, // <- potential to throw NPE before executing the function block! request: WebResourceRequest // <- as well! ): Boolean { return super.shouldOverrideUrlLoading(view, request) } }
En un mot, nous ne devrions pas enlever
?
signer à partir des arguments de la fonction, lorsque la méthode remplacée est définie dans une classe
Java
.
Si une méthode virtuelle Java ne spécifie pas la nullité de ses paramètres, par exemple avec les annotations
@Nullable
/
@NotNull
, vous êtes libre de choisir la nullité d'une manière ou d'une autre lors du remplacement de cette méthode dans Kotlin.
Mais comment choisir
-
Tout d'abord, vous pouvez consulter la documentation de la méthode et vérifier le contrat de la méthode. Cela spécifie-t-il que la méthode peut être appelée avec des valeurs NULL, et que signifieraient ces valeurs NULL lorsqu'elles sont transmises à la méthode?
Dans ce cas particulier, la page de documentation de la méthode WebViewClient.shouldOverrideUrlLoading ne dit rien à propos des WebViewClient.shouldOverrideUrlLoading , elle peut donc être considérée comme une preuve que ses paramètres sont censés être non nullables .
- Deuxièmement, si vous n'êtes toujours pas sûr de la nullité après avoir consulté la documentation, vous pouvez envisager l'utilisation de la valeur du paramètre null, si vous en recevez une. Si la seule chose raisonnable dans cette situation est de générer une exception, vous pouvez déléguer cette vérification au code de vérification de paramètre généré par Kotlin, en déclarant les paramètres comme non nullables.