Нужно ли создавать определенные пользователем исключения для каждой ошибки

Question

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

Причины для создания индивидуальных исключений:

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

Теперь я задаюсь:

1. Нужно ли создавать индивидуальные пользовательские определенные исключения для каждого сценария ошибки?
2. Как большинство людей обрабатывают ошибки и пользовательские исключения лучше?

Answer 1

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

When should we create our own java exception classes?

Answer 2

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

Но если использование исключений связано с серьезными затратами (в нашей среде мы отправляем исключения из «независимых» узлов A в узел B ... и теперь вы внезапно должны убедиться, что A, B находятся на совпадающих уровнях кода) все по-другому. Тогда вы можете подумать очень внимательно, какая архитектура дает вам «возврат инвестиций».

Answer 3

Похоже, что избыток излишков для создания 300 ошибок за 300 исключений. То, что я сделал, это создать собственный класс HttpErrorException, который содержит ошибку HTTP, которую мы хотели бы вернуть. Разработчикам было рекомендовано выбросить один из них, когда они столкнулись с исключением или ошибкой. Если возникла ошибка, которая не была одной из новых HttpErrorExceptions, то возвращается 500. Мы не преобразовали другие исключения в ошибки HTTP, потому что я чувствовал, что ошибочно полагать, что каждое возникновение конкретного Исключения всегда будет отображаться обратно на конкретную ошибку HTTP. Причина этого заключается в том, что существует множество зависимостей (другие библиотеки, которые мы используем), и они могут генерировать любые типы исключений, которые для любой конкретной ситуации могут не отображаться хорошо с ошибкой HTTP, которую мы имели в виду. Поэтому я скорее буду откровенен.

Вот примерный пример типичного использования.

Account getAccount(String id){ 
    Account a = null; 
    try{ 
     a = accountRepo.findById(id); 
    catch(Exception e) { 
     String error = "Got exception while trying to get Account from db."; 
     logger.(error, e); 
     throw new HttpErrorException(500, error); 
     //or throw new HttpErrorException(HttpStatus.INTERNAL_SERVER_ERROR, error); 
    } 
    throw404IfNull(a); 
    return a; 
} 

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

void throw404IfNull(Object obj){ 
    if(obj == null) { 
     throw new HttpErrorException(400, "Object was not found"); 
    } 
} 

Мы используем возможности обработки исключений Spring, чтобы отобразить все HttpErrorException «S на хорошие хорошо отформатированные ошибки HTTP со статусом ошибки, которая находится в исключении.