Collections.CheckedCollection(ICollection, Class) Méthode

[Android.Runtime.Register("checkedCollection", "(Ljava/util/Collection;Ljava/lang/Class;)Ljava/util/Collection;", "")]
[Java.Interop.JavaTypeParameters(new System.String[] { "E" })]
public static System.Collections.ICollection CheckedCollection(System.Collections.ICollection c, Java.Lang.Class type);

[<Android.Runtime.Register("checkedCollection", "(Ljava/util/Collection;Ljava/lang/Class;)Ljava/util/Collection;", "")>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "E" })>]
static member CheckedCollection : System.Collections.ICollection * Java.Lang.Class -> System.Collections.ICollection

Paramètres

Retours

vue dynamique de typesafe de la collection spécifiée

Attributs

RegisterAttribute JavaTypeParametersAttribute

Remarques

Retourne une vue dynamique de typesafe de la collection spécifiée. Toute tentative d’insertion d’un élément du type incorrect entraîne une exécution immédiate ClassCastException. En supposant qu’une collection ne contient aucun élément mal typé avant le moment où une vue de typesafe dynamique est générée et que tout accès ultérieur à la collection a lieu via la vue, il est garanti que la collection ne peut pas contenir d’élément typé incorrectement.

Le mécanisme générique dans le langage fournit la vérification de type au moment de la compilation (statique), mais il est possible de vaincre ce mécanisme avec des casts non vérifiés. En règle générale, ce n’est pas un problème, car le compilateur émet des avertissements sur toutes ces opérations non vérifiées. Toutefois, il arrive parfois que la vérification de type statique seule ne soit pas suffisante. Par exemple, supposons qu’une collection soit passée à une bibliothèque tierce et qu’il est impératif que le code de la bibliothèque n’endommage pas la collection en insérant un élément du type incorrect.

Une autre utilisation des vues de typesafe dynamique est le débogage. Supposons qu’un programme échoue avec un ClassCastExceptionélément, indiquant qu’un élément mal typé a été placé dans une collection paramétrable. Malheureusement, l’exception peut se produire à tout moment après l’insertion de l’élément erroné, de sorte qu’elle fournit généralement peu ou pas d’informations sur la source réelle du problème. Si le problème est reproductible, vous pouvez rapidement déterminer sa source en modifiant temporairement le programme pour encapsuler la collection avec une vue de typesafe dynamique. Par exemple, cette déclaration :

{@code
                Collection<String> c = new HashSet<>();
            }

peut être remplacé temporairement par celui-ci :

{@code
                Collection<String> c = Collections.checkedCollection(
                    new HashSet<>(), String.class);
            }

L’exécution du programme à nouveau entraîne l’échec à l’endroit où un élément mal typé est inséré dans la collection, identifiant clairement la source du problème. Une fois le problème résolu, la déclaration modifiée peut être rétablie à l’origine.

La collection retournée ne transmet pas le code de hachage et les opérations égales à la collection de stockage, mais s’appuie sur Objectles méthodes et hashCode les equals méthodes. Cela est nécessaire pour conserver les contrats de ces opérations dans le cas où la collection de stockage est un ensemble ou une liste.

La collection retournée est sérialisable si la collection spécifiée est sérialisable.

Étant null donné qu’elle est considérée comme une valeur de n’importe quel type de référence, la collection retournée autorise l’insertion d’éléments Null chaque fois que la collection de stockage le fait.

Ajouté à la version 1.5.

Documentation Java pour java.util.Collections.checkedCollection(java.util.Collection<E>, java.lang.Class<E>).

Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.