Как правильно организовать уровни исключений и логирование?

Question

[topuserman]

Мне нужно разработать систему интеграции с различными информационными системами.

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

Для логирования и других уведомлений я выбрал Monolog (только знакомлюсь с монологом).

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

Я искал информацию в разных источниках, нашел несколько статей о работе с исключениями (статья на habr).

UnloggedInterface - этим интерфейсом помечаются эксепшены, которые не надо логировать вообще.

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

OutableInterface - этот интерфейс помечает эксепшены, текст которых можно выдавать пользователю: далеко не каждый эксепшн можно вывести пользователю.

Я не понимаю, какой должна быть иерархия наследования Exception классов? Каким образом нужно связать Monolog (или любую другую систему логирования) с классами исключений ?

Может нужно использовать Monolog\ErrorHandler ? (но я не знаю как) ..

Подскажите пожалуйста, где я могу посмотреть примеры? Или где почитать об этом подробнее?

Я хотел бы понять, как это работает. И посмотрите примеры правильной работы с исключениями и логами.

Можно даже примеры на GitHub))

Буду благодарен за любую помощь.

Answer 1

[dmitriy]

Основная ошибка проектировать исключения с учётом как их будут использовать, использование исключений это задача кода приложения, код приложения может быть разный, может меняться например
Сервис пользователя UserService имеет метод получения пользователя по id на выходе только UserEntity если по каким то причинам нет пользователя то кидани UserNotFoundException
Теперь приложение варианты использования:
1. Для рест апи в контроллере сделаем запрос на получение пользователя и обработав исключение там же отправим ответ 404, отсутствие пользователя не так критично.
2. Есть форма сохранения например товара или заказа, и нужно получит информацию о пользователе по его сессионной id, делаем запрос а пользователя нет, обрабатываем исключение например глобальным обработчиком приложения и логируем, выдаём пользователю уведомление о сбое, вот тут критично. 500 ответ

Comments

[topuserman]

Спасибо! Но мне не понятен такой момент:

Например разрабатываю некий функционал интеграции с 1с, в процессе разработки можен возникать множество Исключительных ситуаций.

Например:
1. исключения, которые не требуют обязательной обработки.
2. исключения, которые нужно только обработать
3. исключения, при возникновении которых нужно обязательно сообщить администратору - добавить инфу в лог. (Не важно обработано исключение или нет)

С первыми двумя пунктами, мне немного понятно как быть. А вот с третьим непонятно, а именно:

В какой момент мне записывать в лог?

Если в момент, когда выбрасываю исключение?

Это нужно делать перед throw new Exception, или нужно в моем классе Exception реализовать методы добавления в лог в зависимости от того, како интерфейс имплементирую (UnloggedInterface, PreloggedInterface и т.д.)?

А как быть с исключениями, которые не обработал?

Если весь функционал обернуть в try - catche, то мне там придется десятки swicth-case перебирать классы экзепшином, чтобы понимать, с каким исключением что делать..

[dmitriy]

1. для начала у вас должен быть глобальный обработчик исключений, что то вроде

try{
   $response = $controller->index();
}
catch(Exception $ex){
   $logger->error($ex);
    $response = Response::create('Uh oh, something broke internally.', 
   Response::HTTP_INTERNAL_SERVER_ERROR);
}
$response->send();

Здесь мы говорим что вызываем метод index контроллера а все исключения что доходят будем логировать и считать критичными

2. контроллер

public function index(){

$syncData = $this->sunc->getSyncData();

foreach($syncData  as $id => $data){

   try{
      $this->sunc->process($data);
      $this->syncLogger->debug("success for data ". $id);
   }
   catch(SyncDataErrorException $ex)
       $this->syncLogger->debug($ex->getMessage());
   }
   catch(SyncAuthErrorException $ex)
       $this->syncLogger->debug($ex->getMessage());
       throw $ex;
   }

}

}

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

В какой момент мне записывать в лог?

в момент ловли исключения

А как быть с исключениями, которые не обработал?

они ловятся в глобальном обработчике

Если весь функционал обернуть в try - catche, то мне там придется десятки swicth-case перебирать классы экзепшином, чтобы понимать, с каким исключением что делать..

в моем примере ни разу не применил swicth-case не понимаю и зачем он вам

[topuserman]

dmitriy, спасибо большое! Так понятнее стало.

в моем примере ни разу не применил swicth-case не понимаю и зачем он вам

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

try{
       ...
   }
   catch(ClassException1 $ex)

   }
   catch(ClassException3 $ex)

   }
   и т.д.

Насколько я понял, необработанные исключения можно отлавливать через set_exception_handler.

В какой момент мне записывать в лог?

в момент ловли исключения

У меня в голове такое представление (не знаю, можно ли делать так, и хорошая ли это практика):

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

Также хотелось бы завести 3 интерфейса, как писал в вопросе

UnloggedInterface - этим интерфейсом помечаются эксепшены, которые не надо логировать вообще.

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

OutableInterface - этот интерфейс помечает эксепшены, текст которых можно выдавать пользователю: далеко не каждый эксепшн можно вывести пользователю.

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

Только как это связать все, чтобы была грамотная архитектура - не знаю.

[dmitriy]

Также хотелось бы завести 3 интерфейса, как писал в вопросе

еще раз напомню вы пытаетесь заранее заложить логику обработки, не нужно так делать. Вот вы пишите

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

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

[topuserman]

dmitriy, понял, спасибо большое за объяснение!