Преобразование кодов ошибок API в исключения

Question

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

• имеет отдельный MyApiThisAndThatError класса для каждого кода ошибки?
• или иметь общий класс MyApiError и предоставить код ошибки API в качестве аргумента?

Я также открыт для альтернативных предложений.

Answer 1

TLDR:Используйте общий класс MyApiException, который включает в себя код API Error.

Ralph Schindler написал хорошую статью по общей теме на http://ralphschindler.com/2010/09/15/exception-best-practices-in-php-5-3

Если вы читаете все это, вы увидите раздел Рекомендации В библиотеке кодекса, который демонстрирует (я изменил свой пример этот контекст):

// usage of bracket syntax for brevity 
namespace MyCompany\Component { 

    interface Exception 
    {} 

    class MyApiException 
     extends \RuntimeException 
     implements Exception 
    {} 

    class Component 
    { 
     public static function doSomething() 
     { 
      $myApiCall->doSomthing(); 
      if ($myApiCall->hasError) { 
       throw new MyApiException($myApiCall->getMessage(), $myApiCall->getErrorCode); 
      } 
     } 
    } 
} 

Предполагая, что приведенный выше код, если бы нужно было выполнить MyCompany \ Component \ Компонента :: DoSomething(), исключение, которое излучается из DoSomething() метод может быть перехвачено любым из следующие типы: Исключение PHP , RuntimeException SPL. Исключение компонента MyCompany \ Component \ MyApiException компонента или компонента MyCompany \ Component \ Exception компонента. Это дает вызывающему абоненту любое количество возможностей для обнаружения исключения, которое исходит от данного компонента в вашей библиотеке, вызванного возвращенной ошибкой API.Кроме того, анализируя типы, составляющие исключение, более семантическое значение может быть дано исключительной ситуации, которая только что произошла.

Answer 2

У меня была аналогичная проблема. Когда я это сделал, я разделил все ошибки на семьи (например, Query, Model, Controller, Form и т. Д.), Затем в каждом семействе ошибок я определил константы для каждого кода ошибки.

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

Answer 3

Это зависит от нескольких факторов. На мой взгляд, это причины для конкретных исключений:

1. Вы можете логически группировать ошибки и логически назвать исключения.
2. У ошибок есть дополнительные данные, которые зависят от типа ошибки (вы можете сохранить эти дополнительные данные, и пользователи могут получить их с помощью set/get).
3. Новые типы ошибок добавляются очень редко (но вы всегда можете бросить какое-то общее общее исключение для неизвестных кодов ошибок).
4. Значение ошибки изменяется во времени (пользователи вашего интерфейса будут основываться на типе исключения, а не на базовом коде ошибки).
5. Вы готовы надлежащим образом документировать ваши конкретные исключения, чтобы пользователям не приходилось искать API-интерфейс поиска на основе базового кода ошибки.