Discussion :

[®om]

C'est dommage, sur les tutoriels, on ne peut pas "réagir" directement, c'est pourquoi je fais un post ici.

Suite à cet article: Constructeurs et méthodes exportées

Je voudrais juste rajouter que l'utilisation des méthodes exportées peut être dangereuse même si l'on n'est pas dans le constructeur... Et c'est quand même tentant si on a une méthode a(int i), et une méthode b() qui fait la même chose que a(5) d'appeler a(5) dans b().

Et aussi que dans Swing (par exemple dans JTabbedPane), ils utilisent des "méthodes exportées" (je ne connaissais même pas le nom), car quand on redéfinit addTab(...) en mettant comme code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

throw new UnsupportedOperationException();

(pour éviter qu'on puisse ajouter un onglet de l'extérieur), et bien ça plante dès le constructeur...

[adiGuba]

Salut,

Je voudrais juste rajouter que l'utilisation des méthodes exportées peut être dangereuse même si l'on n'est pas dans le constructeur... Et c'est quand même tentant si on a une méthode a(int i), et une méthode b() qui fait la même chose que a(5) d'appeler a(5) dans b().

Pour moi ce n'est pas vraiment dangereux en dehors des constructeurs... Au contraire c'est même plutôt utile...

Et aussi que dans Swing (par exemple dans JTabbedPane), ils utilisent des "méthodes exportées" (je ne connaissais même pas le nom), car quand on redéfinit addTab(...) en mettant comme code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

throw new UnsupportedOperationException();

(pour éviter qu'on puisse ajouter un onglet de l'extérieur), et bien ça plante dès le constructeur...

Personne n'a jamais dit que l'API standard respectait toujours les bonnes règles de developpement

a++

[bouye]

Personne n'a jamais dit que l'API standard respectait toujours les bonnes règles de developpement

C'est clair, il suffit meme de regarder le code source de Swing pour s'en rendre compte (mais bon, le code de Swing est bien mieux que celui de l'AWT soit dit en passant).
C'est du genre "faites ce que nos didacticiels disent mais ne faites surtout pas ce qu'on fait nous". Mais bon, ce ne sont pas des pratiques qui sortent de l'ordinaire non plus .

[McFoggy]

Et aussi que dans Swing (par exemple dans JTabbedPane), ils utilisent des "méthodes exportées" (je ne connaissais même pas le nom), car quand on redéfinit addTab(...) en mettant comme code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

throw new UnsupportedOperationException();

(pour éviter qu'on puisse ajouter un onglet de l'extérieur), et bien ça plante dès le constructeur...

Oui d'accord mais ce n'est pas parceque tu redéfinis une méthode que tu dois changer le contrat de la méthode. Il n'a jamais été dit dans l'API de JTabbedPane que tu pouvais lever une exception de ce type en appelant la méthode addTab. A mon avis, pour limiter l'ajout d'onglets, il faudrait juste que tu ta méthode rédéfinie se contente de ne rien faire.

[®om]

Oui d'accord mais ce n'est pas parceque tu redéfinis une méthode que tu dois changer le contrat de la méthode. Il n'a jamais été dit dans l'API de JTabbedPane que tu pouvais lever une exception de ce type en appelant la méthode addTab. A mon avis, pour limiter l'ajout d'onglets, il faudrait juste que tu ta méthode rédéfinie se contente de ne rien faire.

Je ne change pas le "contrat" de la méthode, UnsupportedOperationException étend RuntimeException... Si l'exception est levée au runtime, c'est que la méthode est exécutée (d'ailleurs il doit s'agir d'un add et non d'un addTab).

[McFoggy]

Pour moi changer le comportement d'une méthode en renvoyant même une RuntimeException est un changement de contrat.

Si j'ai une méthode qui est susceptible de lever une exception Runtime elle est décrite dans la javadoc. Sinon c'est qu'elle n'en lève pas. Dans l'exemple suivant j'ai deux méthodes une qui est suceptible de lever une NPE et l'autre pas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
    /**
     * @param s une chaine
     * @return la chaine en majuscule
     * @throws NullPointerException si la chaine est nulle
     */
    public String toUpperCase(String s) {
        return s.toUpperCase();
    }
 
    /**
     * @param s une chaine
     * @return la chaine en majuscule
     */
    public String toUpperCaseSafe(String s) {
        if (s!=null) {
            return s.toUpperCase();
        }
        return null;
    }

Pour moi si jamais tu surcharges toUpperCaseSafe tu n'as pas le "droit" de lancer une NPE, c'est le contrat de ma méthode !

Voilà c'est simplement mon interprétation du @throws qui n'est que trop peu souvent utilisé.

[®om]

J'ai simplement suivi le comportement des unmodifiableCollection:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Collection.unmodifiableList(maList);

Ca renvoie une liste, et si tu fais un add dessus, ça renvoie un UnsupportedOperationException...

[adiGuba]

J'ai simplement suivi le comportement des unmodifiableCollection:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Collection.unmodifiableList(maList);

Ca renvoie une liste, et si tu fais un add dessus, ça renvoie un UnsupportedOperationException...

Justement !

Si tu regarde la doc de la méthode List.add(), tu peux lire ceci :

Throws:
UnsupportedOperationException - if the add method is not supported by this list.
ClassCastException - if the class of the specified element prevents it from being added to this list.
NullPointerException - if the specified element is null and this list does not support null elements.
IllegalArgumentException - if some aspect of this element prevents it from being added to this list.

Ce qui veut dire que la méthode peut renvoyer des UnsupportedOPerationException (entre autres). Donc le contrat est respécté...


Ce n'est pas le cas des méthodes addTab() de JTabbedPane...

a++