Existe algo como o NotImplementedException do .NET em Java?

Existe algo como o NotImplementedException do .NET em Java?

O Commons Lang tem isso. Ou você poderia jogar um UnsupportedOperationException .

Eu acho que o java.lang.UnsupportedOperationException é o que você está procurando.

Você poderia fazer isso sozinho (isso é o que eu fiz) – para não ser incomodado com o tratamento de exceções, você simplesmente estende o RuntimeException, sua class poderia ser algo como isto:

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

Você poderia estendê-lo para levar uma mensagem – mas se você usar o método como eu faço (isto é, como um lembrete, que ainda há algo a ser implementado), então geralmente não há necessidade de mensagens adicionais.

Ouso dizer que só uso esse método, enquanto estou no processo de desenvolvimento de um sistema, fica mais fácil para mim não perder a noção de quais methods ainda não foram implementados corretamente 🙂

Não, não existe e provavelmente não está lá, porque há pouquíssimos usos válidos para isso. Eu pensaria duas vezes antes de usá-lo. Além disso, é realmente fácil criar a si mesmo.

Por favor, refira-se a esta discussão sobre por que é mesmo em .NET.

Eu acho que UnsupportedOperationException chega perto, embora não diga que a operação não é apenas implementada, mas sem suporte mesmo. Isso poderia implicar que nenhuma implementação válida é possível. Por que a operação não teria suporte? Deveria estar lá? Segregação de interface ou problemas de substituição de Liskov, talvez?

Se é um trabalho em andamento, eu prefiro o ToBeImplementedException , mas eu nunca me peguei definindo um método concreto e depois o deixei por tanto tempo que ele entrou em produção e haveria uma necessidade para tal exceção.

Como mencionado, o JDK não tem uma correspondência aproximada. No entanto, minha equipe ocasionalmente tem um uso para tal exceção também. Poderíamos ter ido com UnsupportedOperationException conforme sugerido por outras respostas, mas preferimos uma class de exceção personalizada em nossa biblioteca base que tenha construtores obsoletos:

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

Essa abordagem tem os seguintes benefícios:

  1. Quando os leitores veem NotYetImplementedException , eles sabem que uma implementação foi planejada e foi esquecida ou ainda está em andamento, enquanto UnsupportedOperationException diz (de acordo com os contratos de coleta ) que algo nunca será implementado. É por isso que temos a palavra “ainda” no nome da class. Além disso, um IDE pode listar facilmente os sites de chamadas.
  2. Com o aviso de descontinuidade em cada site de chamada, sua ferramenta de análise de código estático e IDE pode lembrá-lo de onde você ainda precisa implementar algo. (Esse uso de depreciação pode parecer errado para alguns, mas, na verdade, a depreciação não se limita a anunciar a remoção .)
  3. Os construtores são reprovados, não a class. Dessa forma, você só recebe um aviso de desaprovação dentro do método que precisa ser implementado, não na linha de import (o JDK 9 corrigiu isso , no entanto).