O sufixo Exceção em exceções em java

A especificação de um sufixo Exception em classes de exceção parece um cheiro de código para mim (informações redundantes - o restante do nome implica um estado de erro e herda de Exception). No entanto, também parece que todo mundo faz isso e parece ser uma boa prática.

Estou procurando entender por que isso é uma boa prática.

Eu já vi e li a pergunta: por que as exceções geralmente têm a exceção do sufixo no nome da classe

A questão é para PHP e, embora as respostas sejam provavelmente válidas para Java. Existem outros argumentos ou é realmente tão simples quanto diferenciá-los explicitamente?

Se pegarmos os exemplos da pergunta anterior - poderia realmente haver classes em java com o nome FileNoFoundque não é uma exceção? Se houver, justifica o sufixo Exception?

Olhando para uma hierarquia rápida no eclipse de Exception, com certeza, a grande maioria deles tem o sufixo de exceção, mas existem algumas exceções. javassisté um exemplo de uma biblioteca que parece ter algumas exceções sem o sufixo - por exemplo BadByteCode, BadHttpRequestetc.

BouncyCastle é outra lib com exceções como CompileError

Eu pesquisei um pouco também com pouca informação sobre o assunto.

java naming exceptions

— drone.ah
fonte

"Todas as exceções devem conter um Exceptionsufixo ou devemos fazer exceções para exceções excepcionais?" ;)

— tdammers

realmente erro é como exceção (veja OutOfMemoryError), mas eles são voltados para as coisas que são difíceis de recuperar do (assim você quase nunca lidar com eles)

— aberração catraca

Além disso, ouvi dizer que, como regra geral, 'classes devem ser substantivos e métodos devem ser verbos (ações)'. FileNotFound ArrayIndexOutOfBoundse OutOfMemorysão mais observações / descrições, mas são aplicadas ao substantivo Exception.

— 21813 MikeTheLiar

Respostas:

A resposta de Landei é boa, mas também há a resposta gramatical. Os nomes das classes devem ser substantivos . O que é um "OutOfMemory"? O que é um "FileNotFound"? Se você pensa em "Exceção" como o substantivo, o descritor é o adjetivo que o especifica. Não é apenas um Exception, é um FileNotFoundException. Você não precisa pegar OutOfMemorymais do que iria à loja para comprar um "azul".

Isso também aparece se você ler seu código como uma frase: " Tryfazendo ... e catch OutOfMemory Exceptions"

— Bobson
fonte

Para citar o artigo "Tente usar substantivos porque uma classe normalmente representa algo no mundo real". Mas as exceções se enquadram neste caso? Para mim, eles são mais como um artefato de programação, representando uma mensagem de erro. "Você receberá uma OutOfMemoryexceção" é melhor que "Você receberá uma OutOfMemoryExceptionexceção", não é?

— 22716 greg0ire

@ greg0ire - Você deve experimentá-lo como "Você receberá um OutOfMemoryException". Dito isto, também temos números PIN e caixas eletrônicos, portanto uma exceção do OOME não seria tão incomum.

— Bobson 19/07/16

Eu acho que o argumento que você está enfatizando aqui é realmente o melhor (aquele sobre conflitos de nome não se sustenta mais graças aos espaços para nome, pelo menos em php). Tenho mais coisas a dizer sobre tudo isso e publicarei uma resposta em breve.

— Greg0ire

Feito! O que você acha?

— Greg0ire

@Bobson Eu recomendo ler O Reino dos Substantivos . Não precisamos que tudo seja um substantivo. Por que "você receberá um OutOfMemoryException" quando pode simplesmente ser "você está sem memória"? Nós não usamos Classsufixos ( DogClass, CatClass, XmlReaderClass, ...).

— Matthieu Napoli

Acho que exceções (e erros, e teoricamente outros Throwable) são diferentes de coisas como interfaces ou enumerações (que geralmente não são usadas como sufixo): geralmente têm um objetivo muito claro e limitado, são usadas com construções de linguagem especializadas ( try, catch, throw, throws) e seguir as regras especiais (por exemplo verificado vs exceções não verificadas, não genéricos). De certa forma, não são apenas as classes que são usadas como exceções, mas um mecanismo de exceção que é implementado por meio das classes.

Portanto, se você lida com uma exceção e não a reconhece como tal, geralmente algo está profundamente errado (o que também não é o caso de coisas como enumerações ou interfaces). Então, acho que essas diferenças nas classes "normais" são grandes o suficiente para exigir uma pista visual.

— Landei
fonte

Parece auto-contraditório para mim. Se as exceções são especiais e usadas de maneiras especiais e tão obviamente reconhecíveis, por que você precisa de uma pista visual?

— Michael Borgwardt

@ MichaelBorgwardt - Acho que ele está dizendo que, por serem especiais e usados de maneiras especiais, deveriam ter a pista visual de serem obviamente reconhecíveis. Dito isto, não sei se você pode lançar algo que não é herdado Exceptionem Java - você não pode em C #. Se você não puder, não consigo pensar em um cenário em que você "esteja lidando com uma exceção e [não] a reconheça como tal".

— Bobson

Você também não pode lançar não- Throwables em Java. No entanto, você pode lidar com a exceção não apenas nas configurações try- catch, por exemplo, pode coletar exceções ao fazer algum tipo de validação para objetos complexos (quando quiser conhecer todos os problemas relacionados, não apenas o primeiro). Nesses casos, você deve estar ciente de que pode, por exemplo, voltar a jogar as coisas que tem na sua lista, por isso seria ruim chamá-las, ou seja, em ValidationIssuevez de ValidationException.

— Landei

No entanto, também parece que todo mundo faz isso e parece ser uma boa prática.

Sim, todo mundo faz, de fato, por isso é uma prática, mas ainda é bom? Várias pessoas estão questionando isso:

http://mnapoli.fr/approaching-coding-style-rationally/ (O sufixo da exceção § contexto: php)
o vídeo vinculado, https://vimeo.com/album/2661665/video/74316116 (pule para 53:00, context: php), inspira o artigo e destaca que toda vez que você usa uma exceção, você tem uma palavra-chave que já mostra que é uma exceção por perto
http://verraes.net/2013/10/verbs-in-class-names/ mostra como a afirmação na resposta do @Bobson pode não ser absoluta e afirma que, às vezes, o sufixo é bom, para aplicação ou exceções no nível da infraestrutura e, às vezes, você deve tentar salvar os caracteres usados por esse sufixo longo para expressar algo mais preciso e significativo. Este ponto só faz sentido se você usar um idioma em que a cultura use exceções para violações das regras de negócios.
o link SO que você fornece destaca os conflitos de nome, mas agora temos espaços para nome, não é?

— greg0ire
fonte

Esta é uma pergunta sobre Java , não sobre PHP . Os idiomas são diferentes entre os idiomas. Dito isto, discordo totalmente desta citação do seu terceiro link: "Exceções podem ser semelhantes a eventos, ... com a nuance de que é um evento indesejável, um aviso de que alguma operação foi inconsistente com, por exemplo, regras de negócios que estão em vigor ". Talvez o PHP seja diferente sobre isso, mas, na minha opinião, as exceções devem ser excepcionais. Se uma regra de negócios for violada da maneira esperada, sua lógica normal deve lidar com ela - não é uma exceção ao comportamento normal.

— Bobson

Você pode estar certo, pois isso varia de acordo com o idioma: consulte este tópico sobre python: gossamer-threads.com/lists/python/python/796627 . O php e o python claramente não são focados no desempenho, talvez por isso exista essa diferença com o java (que é focado no desempenho, certo?). Se você tiver várias camadas para atravessar na pilha de chamadas antes de estar no nível certo para lidar com a violação das regras de negócios corretamente, as exceções são as melhores para IMO. Também torna os tipos de retorno mais consistentes (você sempre retorna o mesmo tipo, não falso ou verdadeiro). Vou editar a minha resposta isso em conta

— greg0ire