, в котором пространство имен/пакет помещать исключения

Question

Какова общая или лучшая практика для структурирования местоположения ваших классов исключений?

Допустим, у вас есть пакеты/пространств имен myproject.person (модели и объектов DAO для лиц) и myproject.order (модели и объектов DAO для заказов) и исключения PersonException и OrderException. Должны ли я помещать исключения в их соответствующие пакеты или в отдельный пакет для исключений (например, myproject.exceptions)?

Первый подход кажется более разумным (потому что он отсортирован по функциональности). Но возникает вопрос, где вы должны ставить исключения, связанные с обоими? например ConstraintViolationException

Благодаря

Answer 1

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

Answer 2

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

Answer 3

Выполняйте то, что делает библиотека классов Java. Поместите исключения в те же пакеты, что и классы API и интерфейсы, которые их бросают.

Answer 4

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

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

Answer 5

Если исключение используется только для одного класса или функциональности группы классов, поставьте его рядом с ними. Если Exception имеет общее значение для библиотеки приложений jr, поместите ее в свое пространство имен oun. ИМХО

Answer 6

У меня есть проблема с всей этой идеи состоит в том, что исключения должны быть главным образом направлены вдоль линии, что может пойти не так, как NullPointerException, в то время как PersonException, кажется, относится к объекту, вовлеченного в какой бы катастрофа разворачивается, не давая подсказка о том, что пошло не так. Вызывает ли объект Person исключение? Это потому, что у Человека есть внутренняя логическая проблема или из-за того, что плохие аргументы были предоставлены одному из его методов? Или это исключение из-за того, что Лицо не найдено в базе данных?

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

Answer 7

Представьте себе, что каждый узел имеет свои собственные операции, и многие типы исключений (не только PersonException или OrderException, но PersonInvalidDataException или PersonDataPersistException). Эти исключения могут реализовывать BaseException, который регистрирует и отправляет электронные письма, например.

Таким образом, более доступным способом (на мой взгляд) является разделение их на пространство имен.