В чём смысл ContainerExceptionInterface в PSR-11?

Question

[Дмитрий]

PSR-11 говорит:

Exceptions directly thrown by the container SHOULD implement the Psr\Container\ContainerExceptionInterface.

A call to the get method with a non-existing id MUST throw a Psr\Container\NotFoundExceptionInterface.

В чём смысл этих интерфейсов, если по факту они пустые?

<?php
namespace Psr\Container;

/**
 * Base interface representing a generic exception in a container.
 */
interface ContainerExceptionInterface
{
}

<?php
namespace Psr\Container;

/**
 * No entry was found in the container.
 */
interface NotFoundExceptionInterface extends ContainerExceptionInterface
{
}

Answer 1

[Алексей Уколов]

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

Comments

[Дмитрий]

Назначение интерфейса — указать, какие методы должен реализовать имплементирующий его класс, не так ли? Зачем тогда нужен пустой интерфейс, который ничего не указывает?

[Flying]

Дмитрий, Нет, назначение интерфейса - определение контракта, он не обязан содержать дополнительную информацию о методах. Пустой интерфейс определяет тип, а также, возможно, его иерархию (через extends). При этом вам открывается возможность использовать все функции языка, связанные с типами: указание типов свойств, аргументов, возвращаемых значений, использование instanceof и т.п. Все они ничего не говорят о содержимом типа, только о самом типе.

[Дмитрий]

Flying, а какой именно контракт определяет пустой интерфейс? В чем практическая польза знать, что

$var instanceof ContainerExceptionInterface === true

?

[Daria Motorina]

Дмитрий, реализация пустого интерфейса это условная метка, это значит что класс начинает входить в какую-то группу более высокого уровня. Благодаря этому в коде можно уходить от конкретики при тайпхинтинге, можно указывать тип элемента как SomethingInterface $somethingClassInstance, и под это определение подойдут любые реализации интерфейса. Можно почитать про принцип подстановки Барбары Лисков, во многих шаблонах проектирования используется этот подход. Тут нет потребности реализовывать методы, только заставить класс явно входить в какую-то логическую группу и оперировать понятием группы, а не конкретной реализации

[Flying]

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

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

Вопрос: какой exception вы будете ловить?

• Перечислять все, о которых вы в курсе? А если добавят ещё?
  
• Ловить \Throwable? А если вам нужно разделить exception логики контейнера и, к примеру, его хранилища, являющегося внешним механизмом?
  

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

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

К примеру, посмотрите на структуру исключений контейнера в Symfony, там как раз хорошо видно то, что я описываю.

[Дмитрий]

Daria Motorina, Flying, благодарю за ответы, очень полезно и информативно.

Answer 2

[Denis]

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

Comments

[Дмитрий]

Это я понимаю. Просто PSR-11 предписывает мне для выбрасывать именно Psr\Container\NotFoundExceptionInterface. Зачем я, создавая свой класс для исключения, должен имплементировать этот интерфейс, если он мне не сообщает никакой информации о методах?

[Denis]

Дмитрий,
В надежде на то что возможно вы делаете модуль который будут юзать другие люди (девелоперы), и вот эти люди сделали Адаптер (или декоратор) своего решения и в замен другой реализации контейнера другой библиотеки и решили заюзать вашу реализацию контейнера, и эти люди в своем должны обрабатывать NotFoundExceptionInterface поскольку он задокументирован а не лазить по коду и искать Ваш эксепшен