Суффикс Исключение на исключениях в Java

Задание суффикса Exception для классов исключений выглядит для меня как запах кода (избыточная информация - остальная часть имени подразумевает состояние ошибки и наследуется от Exception). Однако, кажется, что все так делают, и это хорошая практика.

Я хочу понять, почему это хорошая практика.

Я уже видел и читал вопрос, почему у исключений обычно есть исключение суффикса в имени класса

Вопрос касается PHP и, хотя ответы, вероятно, действительны для Java. Существуют ли другие аргументы или это действительно так просто, как явно их дифференцировать?

Если мы возьмем примеры из предыдущего вопроса - действительно ли могут быть классы в Java с именем FileNoFound, которое не является исключением? Если это возможно, то оправдывает ли это суффикс Exception?

Если взглянуть на быструю иерархию в затмении, то Exception, конечно же, подавляющее большинство из них имеют суффикс исключения, но есть несколько исключений. javassistпример библиотеки, которая, кажется, имеет несколько исключений без суффикса - например BadByteCode, BadHttpRequestи т. д.

BouncyCastle это еще одна библиотека с исключениями, такими как CompileError

Я также немного погуглил с небольшой информацией по этому вопросу.

java naming exceptions

— drone.ah
источник

«Должны ли все исключения иметь Exceptionсуффикс, или мы должны делать исключения для исключительных исключений?» ;)

— tdammers

на самом деле ошибка похожа на исключение (см. OutOfMemoryError), но они предназначены для вещей, которые трудно восстановить (так что вы почти никогда не имеете с ними дело)

— ratchet freak

Также я слышал, что по общему правилу «классы должны быть существительными, а методы - глаголами (действиями)». FileNotFound ArrayIndexOutOfBoundsи OutOfMemoryбольше наблюдений / описаний, но затем применяются к существительному Exception.

— MikeTheLiar

Ответы:

Ответ Ландеи хороший, но есть и грамматический ответ. Имена классов должны быть существительными . Что такое "OutOfMemory"? Что такое "FileNotFound"? Если вы думаете об «Исключении» как существительном, тогда дескриптор - это прилагательное, определяющее его. Это не просто любой Exception, это FileNotFoundException. Вам не нужно ловить OutOfMemoryбольше, чем идти в магазин, чтобы купить «синий».

Это также проявляется, если вы читаете ваш код в виде предложения: " Tryделаю ... и catch OutOfMemory Exceptions"

— Bobson
источник

Цитирую статью «Попробуйте использовать существительные, потому что класс обычно представляет что-то в реальном мире». Но попадают ли исключения в этот случай? Для меня они больше похожи на программный артефакт, представляющий сообщение об ошибке. «Вы получите OutOfMemoryисключение» читается лучше, чем «Вы получите OutOfMemoryExceptionисключение», не так ли?

— greg0ire

@ greg0ire - Вы должны попробовать это как "Вы получите OutOfMemoryException." Тем не менее, у нас также есть номера PIN и банкоматы, поэтому исключение OOME не было бы , что необычно.

— Бобсон

Я думаю, что точка зрения, которую вы здесь делаете, действительно лучшая (та, которая касается конфликтов имен, больше не сохраняется благодаря пространствам имен, по крайней мере, в php). У меня есть еще что сказать обо всем этом, и скоро опубликую ответ.

— greg0ire

Выполнено! Как вы думаете?

— greg0ire

@ Бобсон, я рекомендую прочитать Королевство Существительных . Нам не нужно, чтобы все было существительным. Почему «вы получаете OutOfMemoryException» , когда это может быть просто «вы находитесь из памяти»? Мы не используем Classсуффиксы ( DogClass, CatClass, XmlReaderClass...).

— Матье Наполи

Я думаю, что исключения (и ошибки, и теоретически другие Throwable) отличаются от таких вещей, как интерфейсы или перечисления (которые обычно не используются в качестве суффикса): они обычно имеют очень четкое и ограниченное назначение, они используются со специальными языковыми конструкциями ( try, catch, throwи throws) и следуйте специальным правилам (например, отмеченные и непроверенные исключения, никаких обобщений). В некотором смысле это не просто классы, которые используются в качестве исключений, а механизм исключений, который реализуется с помощью классов.

Так что, если вы имеете дело с исключением и не распознаете его как таковое, обычно что-то глубоко неправильно (что опять-таки не так для вещей, таких как перечисления или интерфейсы). Поэтому я думаю, что эти отличия от «обычных» классов достаточно велики, чтобы вызвать визуальную подсказку.

— Landei
источник

Звучит противоречащим мне. Если исключения являются такими особыми и используются особым образом и настолько очевидны, зачем вам нужен визуальный ключ?

— Майкл Боргвардт

@MichaelBorgwardt - я думаю, он говорит, что, поскольку они особенные и используются особым образом, они должны иметь визуальную подсказку, чтобы быть явно узнаваемой. Это , как говорится, я не знаю , даже будь вы можете бросить что - то , что не унаследованный от Exceptionв Java - вы не можете в C #. Если вы не можете, то я не могу придумать сценарий, в котором вы будете «иметь дело с исключением и [не] распознавать его как таковое».

— Бобсон

Вы не можете бросить nons Throwableв Java, либо. Однако вы можете иметь дело с исключениями не только в параметрах try- catch, например, вы можете собирать исключения, когда выполняете какую-то проверку для сложных объектов (когда вы хотите знать все связанные проблемы, а не только первую). В таких случаях вы должны знать, что вы можете, например, перебрасывать вещи, которые есть в вашем списке, поэтому было бы плохо называть их, т.е. ValidationIssueвместо ValidationException.

— Landei

Однако, кажется, что все так делают, и это хорошая практика.

Да, все так и делают, так что это практика, но разве это хорошо? Несколько человек спрашивают, что:

http://mnapoli.fr/approaching-coding-style-rationally/ (Суффикс исключений § context: php)
Связанное видео https://vimeo.com/album/2661665/video/74316116 (перейдите к 53:00, context: php) вдохновляет статью и подчеркивает, что каждый раз, когда вы используете исключение, у вас есть ключевое слово что уже показывает, что это исключение поблизости
http://verraes.net/2013/10/verbs-in-class-names/ показывает, как утверждение в ответе @Bobson может быть не абсолютным, и подчеркивает, что иногда суффикс хорош для приложения или исключения уровня инфраструктуры, и иногда вы должны пытаться сохранить символы, взятые этим длинным суффиксом, чтобы выразить что-то более точное и значимое. Этот пункт имеет смысл только в том случае, если вы используете язык, в котором культура использует исключения для нарушений бизнес-правил.
SO ссылки вы обеспечиваете делают пункты о конфликте имен, но теперь у нас есть пространство имен, не так ли?

— greg0ire
источник

Это вопрос Java , а не php . Идиомы разные в разных языках. Тем не менее, я категорически не согласен с этой цитатой из вашей третьей ссылки: «Исключения могут быть похожи на события ... с тем нюансом, что это нежелательное событие, предупреждение о том, что какая-то операция была несовместима, например, с бизнес-правилами, которые в действии. " Возможно, PHP отличается от этого, но, на мой взгляд, исключения должны быть исключительными. Если бизнес-правило нарушается каким-либо ожидаемым образом, ваша обычная логика должна его обрабатывать - это не исключение из нормального поведения.

— Бобсон

Вы можете быть правы в том, что он варьируется в зависимости от языка: см. Эту ветку про python: gossamer-threads.com/lists/python/python/796627 . php и python явно не ориентированы на производительность, поэтому, возможно, в этом и заключается разница с java (которая ориентирована на производительность, верно?). Если у вас есть несколько уровней, которые нужно пересечь в стеке вызовов, прежде чем вы попадете на правильный уровень для правильной обработки нарушения бизнес-правил, исключения являются лучшим IMO. Это также делает типы возвращаемых данных более согласованными (вы всегда возвращаете один и тот же тип, а не false или true). Я отредактирую свой ответ на этот вопрос

— greg0ire