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

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

Commons Lang l’ a. Ou vous pourriez lancer une UnsupportedOperationException .

Je pense que java.lang.UnsupportedOperationException est ce que vous recherchez.

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 le 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 (pour vous rappeler qu’il y a encore quelque chose à implémenter), vous n’avez généralement 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, cela me permet de ne pas perdre la trace des méthodes qui ne sont toujours pas implémentées correctement 🙂

Non, il n’y en a pas et ce n’est probablement pas là, car il y a très peu d’utilisations valables pour cela. Je réfléchirais à deux fois avant de l’utiliser. En outre, il est en effet facile de se créer.

S’il vous plaît se référer à cette discussion sur pourquoi il est même dans .NET.

Je suppose que UnsupportedOperationException est proche, bien qu’il ne soit pas indiqué que l’opération n’est pas implémentée, mais qu’elle n’est même pas prise en charge. Cela pourrait impliquer qu’aucune implémentation valide n’est possible. Pourquoi l’opération ne serait-elle pas prise en charge? Devrait-il même être là? Ségrégation d’interface ou problèmes de substitution Liskov peut-être?

Si le travail est en cours, j’irais pour ToBeImplementedException , mais je ne me suis jamais aperçu de définir une méthode concrète et la laisser si longtemps en production et qu’une telle exception serait nécessaire.

Comme mentionné, le JDK n’a pas de correspondance étroite. Cependant, mon équipe a parfois une utilisation pour une telle exception. Nous aurions pu aller avec UnsupportedOperationException comme 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 des constructeurs obsolètes:

 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(Ssortingng message) { super(message); } } 

Cette approche présente les avantages suivants:

  1. Lorsque les lecteurs voient NotYetImplementedException , ils savent qu’une implémentation a été planifiée et a été oubliée ou est toujours en cours, alors que UnsupportedOperationException indique (conformément aux contrats de collecte ) que quelque chose ne sera jamais implémenté. 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’appel.
  2. Avec l’avertissement de dépréciation à chaque site d’appel, votre outil d’parsing IDE et de code statique peut vous rappeler où vous devez encore implémenter quelque chose. (Cette utilisation de la dépréciation peut sembler erronée pour certains, mais en fait, la déchéance ne se limite pas à l’annonce de la suppression .)
  3. Les constructeurs sont obsolètes, pas la classe. De cette façon, vous ne recevez qu’un avertissement de dépréciation dans la méthode à implémenter, pas sur la ligne d’ import (JDK 9 a cependant corrigé cela ).