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++

[®om]

Et donc que proposes-tu pour empêcher l'ajout d'onglets par une autre méthode?

Ne rien faire est encore pire que de lever une UnsupportedOperationException, car tu ne t'en aperçoit même pas qu'il y a une erreur...

(et si le constructeur appelle la méthode, que tu ne fasses rien ou que tu lèves une exception, au final il y aura un problème)

[McFoggy]

Ne rien faire est encore pire que de lever une UnsupportedOperationException, car tu ne t'en aperçoit même pas qu'il y a une erreur...

Si ton but est de ne pas autoriser l'ajout au travers de cette méthode je ne vois pas comment ne rien faire pourrait être considéré comme une erreur ?

Après je ne me suis pas plongé dans le code de JTabbedPane pour pouvoir dire si il faut faire de telle ou telle façon je disais simplement que si la méthode que tu surcharges ne précise pas des exceptions même Runtime alors tu ne dois pas en renvoyer.

[adiGuba]

Et donc que proposes-tu pour empêcher l'ajout d'onglets par une autre méthode?

Cela ne me semble pas une mauvaise solution... mais le fait est que tu casses le contrat initial. Cela ne me choque pas mais peut avoir des effets nefaste (comme celui que tu décris).

Remarque cela a déjà été fait par exemple pour la méthode add() des JFrame/JWindow qui provoquait une exception avant Java 5.0...

Ne rien faire est encore pire que de lever une UnsupportedOperationException, car tu ne t'en aperçoit même pas qu'il y a une erreur...

Tout à fait d'accord sur ce point.

(et si le constructeur appelle la méthode, que tu ne fasses rien ou que tu lèves une exception, au final il y aura un problème)

Tu aurais encore le code ? Parce qu'il y a une chose que je ne comprend pas : le constructeur de JTabbedPane ne semble pas faire appel à add() ou addTab()...

Je viens de tester en redéfinissant toutes les méthodes add() ou addTab() pour qu'elles lancent une exception, mais je n'ai pas de problème à utiliser cette classe...

a++

[®om]

Non j'avais supprimé ce code...

Mais dès que je créais un JTabbedPane et que je l'ajoutais à un JPanel, ça plantait si les méthodes add() renvoyaient une exception...