Есть ли преимущество для упаковки исключений с пользовательскими типами исключений в Java

Question

У меня есть класс XYZ, публичные функции которого выдают Exception s.

Мне сообщили, что все открытые функции, предоставляемые XYZ, должны генерировать исключения, называемые XYZDataException или XYZSystemException.Поэтому, даже если я получу другие исключения в открытых методах, их нужно обернуть этими XYZException с.

У меня есть пара вопросов:

1. В чем преимуществоОбтекание исключений с помощью XYZException?
2. В чем преимущество разграничения между исключениями System и Data?

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

Answer 1

Большая часть обработки исключений зависит от того, как вы планируете расширить его позже.Например, если бы разработчик B пришел и захотел изменить часть вашего кода, было бы намного проще, если бы он понял, что означает Exception, что в каком случае.В этом случае наличие особых исключений имеет больше смысла.

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

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

Надеюсь, это поможет!

Answer 2

Да, это означает, что они могут быть явно перехвачены кодом, который знает, как их обрабатывать.

например, представьте, что у вас было:

class MyRecoverableException extends Exception {
   ...
}

После этого вы можете получить код, который может автоматически различать их и реагировать соответствующим образом, например:

try{
// ... do something ...
}catch(MyRecoverableException e) {
   // Recover
}catch(Throwable t) {
   // Log fatal reason, and exit gracefully.
}

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

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

Answer 3

Согласно msdn :

Чтобы обернуть исключение, вы указываете его как внутреннее исключение нового исключения, а затем выбрасываете новое исключение.Эту практику следует использовать только в ситуациях, когда исходное исключение не имеет смысла для лица, получившего исключение, или стек вызовов для исключения вводит в заблуждение или неинтересен.

Answer 4

Как обычно, «это зависит». Как правило, не имеет смысл слепо создавать иерархию исключений для каждого класса. Специфичные для приложения исключения должны группировать исключения способом, значимым для этого конкретного приложения, поэтому могут быть исключения верхнего уровня, а затем подклассифицированные исключения для таких вещей, как уровень данных, уровень связи, утилиты и т. Д.

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

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

Answer 5

Предположим, что метод M1 задокументирован как выдающий исключение типа X, когда возникает какое-либо условие.M1 вызывает метод M2, который вызывает исключение типа X, которое M1 не готов обработать.Если M1 не поймает исключение из M2, вызывающая сторона вряд ли поймет, что исключение, выброшенное из M1, не является X, выброшенным M1, а вместо этого X, выброшенным M2, и его практическое значение и последствия могутбыть совсем другим.Наличие M1, создающего исключение типа, который никогда не будет выброшен M2, может избежать этой проблемы (хотя могут все еще быть проблемы, если M2 мог бы вызвать M1 на некотором другом объекте).