¿Hay algo como NotImplementedException de .NET en Java?

¿Hay algo como NotImplementedException de .NET en Java?

Commons Lang lo tiene. O puedes lanzar una UnsupportedOperationException .

Creo que java.lang.UnsupportedOperationException es lo que estás buscando.

Puede hacerlo usted mismo (eso es lo que hice): para no preocuparse por el manejo de excepciones, simplemente extienda la excepción RuntimeException, su clase podría tener este aspecto:

 public class NotImplementedException extends RuntimeException { private static final long serialVersionUID = 1L; public NotImplementedException(){} } 

Podría extenderlo para tomar un mensaje, pero si usa el método como lo hago yo (es decir, como un recordatorio, todavía hay algo que implementar), entonces generalmente no hay necesidad de mensajes adicionales.

Me atrevo a decir que solo uso este método, mientras estoy en el proceso de desarrollar un sistema, hace que sea más fácil para mí no perder de vista qué métodos aún no están implementados correctamente 🙂

No, no hay y probablemente no esté allí, porque hay muy pocos usos válidos para ello. Lo pensaría dos veces antes de usarlo. Además, es realmente fácil crearte a ti mismo.

Por favor, consulte esta discusión acerca de por qué es incluso en .NET.

Supongo que UnsupportedOperationException se acerca, aunque no dice que la operación simplemente no está implementada, pero tampoco es compatible. Eso podría implicar que no es posible una implementación válida. ¿Por qué la operación no sería compatible? ¿Debería estar allí? ¿Segregación de la interfaz o problemas de sustitución de Liskov tal vez?

Si se trata de un trabajo en curso, ToBeImplementedException por ToBeImplementedException , pero nunca me sorprendí definiendo un método concreto y luego lo dejo durante tanto tiempo que entra en producción y habría una necesidad de tal excepción.

Como se mencionó, el JDK no tiene una coincidencia cercana. Sin embargo, mi equipo ocasionalmente también tiene un uso para tal excepción. Podríamos haber ido con UnsupportedOperationException como lo sugieren otras respuestas, pero preferimos una clase de excepción personalizada en nuestra biblioteca base que tiene constructores en desuso:

 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); } } 

Este enfoque tiene los siguientes beneficios:

  1. Cuando los lectores ven NotYetImplementedException , saben que una implementación se planificó y se olvidó o aún está en curso, mientras que UnsupportedOperationException dice (en línea con los contratos de cobranza ) que algo nunca se implementará. Es por eso que tenemos la palabra “todavía” en el nombre de la clase. Además, un IDE puede enumerar fácilmente los sitios de llamadas.
  2. Con la advertencia de desactivación en cada sitio de llamadas, su IDE y la herramienta de análisis de código estático le pueden recordar dónde todavía tiene que implementar algo. (Este uso de desaprobación puede parecer incorrecto para algunos, pero de hecho la desaprobación no se limita a anunciar la eliminación ).
  3. Los constructores están en desuso, no la clase. De esta forma, solo recibirá una advertencia de desaprobación dentro del método que necesita implementarse, no en la línea de import (sin embargo, JDK 9 solucionó esto ).