Existe-t-il quelque chose comme NotImplementedException de .NET en Java?


Réponses:


516

Commons Lang l' a. Ou vous pouvez lancer un UnsupportedOperationException.


26
Il semble que NotImplementedException a été supprimé de Commons Lang 3.0.
Michael Younkin

13
Je pense que puisque l'UnsupportedOperationException fait partie du cadre des collections, il ne devrait être utilisé que s'il est utilisé dans le contexte des collections. Sinon, une RuntimeException doit être utilisée. docs.oracle.com/javase/7/docs/technotes/guides/collections/…
L.Butz

9
@LeonardButz Il vient de java.lang: docs.oracle.com/javase/1.5.0/docs/api/java/lang/…
Ravi Wallau

5
@RaviWallau J'ai vu ceci: docs.oracle.com/javase/7/docs/api/java/lang/… Il semble que cette classe soit membre du Java Collection Framework.
L.Butz

3
Il a été readded dans Commons Lang 3.2: commons.apache.org/proper/commons-lang/javadocs/api-3.2
qwertzguy

289

Je pense que java.lang.UnsupportedOperationExceptionc'est ce que vous recherchez.


28
Je dis que c'est quelque chose de tout à fait différent. Le NIE dit également qu'il n'est peut-être pas encore implémenté, où l'UOE me dit qu'il ne le sera jamais ...
Dykam

5
@Dykam, alors ne serait-ce pas une exception NotImplementedYetException?
Yishai

106
@Dykam: new UnsupportedOperationException("Not implemented yet")- heureux?
Michael Borgwardt

3
Je ne voulais pas dire que c'était pire, juste eu un cas d'utilisation différent.
Dykam

6
la nouvelle UnsupportedOperationException ("Pas encore implémentée") est une idée géniale! :) dans lang3 pour une raison quelconque, je n'ai pas NotImplementedException, c'est donc une excellente solution
ufk

55

Vous pouvez le faire vous-même (c'est ce que j'ai fait) - afin de ne pas être dérangé par la gestion des exceptions, vous étendez simplement la RuntimeException, votre classe pourrait ressembler à ceci:

public class NotImplementedException extends RuntimeException {

    private static final long serialVersionUID = 1L;

    public NotImplementedException(){}
}

Vous pouvez l'étendre pour prendre un message - mais si vous utilisez la méthode comme je le fais (c'est-à-dire, pour rappel, qu'il y a encore quelque chose à implémenter), alors généralement il n'y a pas besoin de messages supplémentaires.

J'ose dire que je n'utilise que cette méthode, alors que je suis en train de développer un système, il est plus facile pour moi de ne pas perdre de vue quelles méthodes ne sont toujours pas implémentées correctement :)


3
J'aime le mieux cette solution car il est facile d'avoir un gestionnaire d'erreur spécial, il est facile de le rechercher en trouvant toutes les références au constructeur NotImplementedException, et ce ne sont que quelques lignes de code. Mais il est un peu gênant de devoir déclarer une nouvelle classe avec son propre fichier.
D Coetzee

1
Je suis d'accord. C'est mieux que l'utilisation de UnsupportedOperationExceptionà mon avis. Maintenant, si seulement Java ajoutait cela à la bibliothèque commune d'exceptions!
écraser le

12

Comme mentionné, le JDK n'a pas de correspondance étroite. Cependant, mon équipe peut aussi parfois utiliser une telle exception. Nous aurions pu y aller UnsupportedOperationExceptioncomme suggéré par d'autres réponses, mais nous préférons une classe d'exception personnalisée dans notre bibliothèque de base qui a déprécié les constructeurs:

public class NotYetImplementedException extends RuntimeException
{
    /**
     * @deprecated Deprecated to remind you to implement the corresponding code
     *             before releasing the software.
     */
    @Deprecated
    public NotYetImplementedException()
    {
    }

    /**
     * @deprecated Deprecated to remind you to implement the corresponding code
     *             before releasing the software.
     */
    @Deprecated
    public NotYetImplementedException(String message)
    {
        super(message);
    }
}

Cette approche présente les avantages suivants:

  1. Quand les lecteurs voient NotYetImplementedException, ils savent qu'une mise en œuvre a été planifiée et a été oubliée ou est toujours en cours, alors que UnsupportedOperationExceptiondit (conformément aux contrats de collecte ) que quelque chose ne sera jamais mis en œuvre. C'est pourquoi nous avons le mot "encore" dans le nom de la classe. En outre, un IDE peut facilement répertorier les sites d'appels.
  2. Avec l'avertissement de dépréciation sur chaque site d'appel, votre IDE et votre outil d'analyse de code statique peuvent vous rappeler où vous devez encore implémenter quelque chose. (Cette utilisation de la dépréciation peut sembler répréhensible à certains, mais en fait, la dépréciation ne se limite pas à annoncer le retrait .)
  3. Les constructeurs sont obsolètes, pas la classe. De cette façon, vous obtenez uniquement un avertissement de dépréciation à l'intérieur de la méthode qui doit être implémentée, pas au niveau de la importligne (cependant, JDK 9 a corrigé cela ).

8

Non, il n'y en a pas et ce n'est probablement pas là, car il y a très peu d'utilisations valides pour cela. J'y réfléchirais à deux fois avant de l'utiliser. De plus, il est en effet facile de se créer soi-même.

Veuillez vous référer à cette discussion pour savoir pourquoi il est même dans .NET.

j'imagine UnsupportedOperationException se rapproche, même si cela ne dit pas que l'opération n'est tout simplement pas implémentée, mais non prise en charge même. Cela pourrait impliquer qu'aucune implémentation valide n'est possible. Pourquoi l'opération ne serait-elle pas prise en charge? Doit-il même être là? Problèmes de ségrégation d'interface ou de substitution Liskov peut-être?

Si c'est un travail en cours, je choisirais ToBeImplementedException, mais je ne me suis jamais surpris à définir une méthode concrète, puis à la laisser si longtemps qu'elle est mise en production et il faudrait une telle exception.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.