Зачем в zf2 пустой интерфейс для пустого Exception?

[fawkes]

Не ну наследовать ErrorException extends \Exception нормально, но зачем implements ExceptionInterface???

https://github.com/zendframework/zf2/tree/master/library/Zend/Db/Exception
https://github.com/zendframework/zf2/blob/master/library/Zend/Db/Exception/ErrorException.php
https://github.com/zendframework/zf2/blob/master/library/Zend/Db/Exception/ExceptionInterface.php

 

[hell0w0rd]

ООП для ООП чтобы ООП, очевидно же!
С другой стороны туда что-то добавят в новой версии, сразу будет понятно, что нужно дописать. А без этого будете долго искать где и что не так

 

[fixxxer]

Задел на будущее, чтобы не пришлось ничего переписывать, если

1) в ErrorException добавятся методы, которые не нужны в общем ExceptionInterface
2) появится FooBarException extends \Exception implements ExceptionInterface в котором нафиг не нужны методы из ErrorException, добавленные в п.1

Практика показывает, что такие заделы остаются невостребованными в 99% случаев. Но зато тру канонични оопэ. =)

 

[fawkes]

причем в symfony сделано похоже, никто не знает почему выбран такой путь работы с exception, где все они implements от базового ExceptionInterface;
Странно еще то, что данный интерфейс определен для каждого пакета и эксепшены тож повторяются.
В чем соль?
https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Routing/Exception

 

[fawkes]

Практика показывает, что такие заделы остаются невостребованными в 99% случаев.

То бишь нафиг все это? Какие еще способы есть?

 

[fixxxer]

Для фреймворка, в котором планируется обеспечивать обратную совместимость годами и десятилетиями, это нормально.

В обычном приложении это классический оверинжиниринг.

Касаемо симфони2 - ну вообще там перебор с ООП-трушностью, на мой вкус, как раз тот самый оверинжинириг во все поля. С другой стороны, эта ООП-трушность позволяет использовать symfony2-компоненты отдельно, с минимальными зависимостями, в других фреймворках (см. laravel), что хорошо.

Универсального ответа "как надо делать всегда", конечно же, не существует.

 

[fawkes]

fixxxer
то есть будет разумно использовать interface и exception в отдельно? Они будут как бы глобальны для всех существующих классов

 

[fawkes]

ООП-трушность === классический оверинжиниринг ?

 

[Вурдалак]

1) в ErrorException добавятся методы, которые не нужны в общем ExceptionInterface
2) появится FooBarException extends \Exception implements ExceptionInterface в котором нафиг не нужны методы из ErrorException, добавленные в п.1

Что? Добавление методов в два несвязанных класса друг друга никак не влияет, причем тут интерфейс?

 

[fixxxer]

Я пропустил пару пунктов логической цепочки =)

Допустим, так.
Часть нужных framework-wide методов идет в ExceptionInterface, часть локальных для ErrorException идут в ErrorException, но не идут в ExceptionInterface.
Теперь захотелось сделать FooException implements ExceptionInterface, с другой реализацией методов из ExceptionInterface но несовместимый с ErrorException.

Где-то есть catch ErrorException, где-то есть catch ExceptionInterface.

 

[hell0w0rd]

ООП-трушность === классический оверинжиниринг ?

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

 

[fixxxer]

ООП-трушность === классический оверинжиниринг ?

Нет. Просто всегда может быть перебор.

 

[fawkes]

ООП-трушность позволяет использовать symfony2-компоненты отдельно, с минимальными зависимостями, в других фреймворках (см. laravel), что хорошо.

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

 

[fawkes]

Универсального ответа "как надо делать всегда", конечно же, не существует

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

 

[Вурдалак]

Часть нужных framework-wide методов идет в ExceptionInterface, часть локальных для ErrorException идут в ErrorException, но не идут в ExceptionInterface.

Добавление локальных для ErrorException вообще ни на что не влияет.

catch ExceptionInterface

Это невозможно, PHP можно ловить только instanceof \Exception.

с другой реализацией методов из ExceptionInterface но несовместимый с ErrorException.

Как это понимать?

Можно кодом?

 

[fixxxer]

Это невозможно, PHP можно ловить только instanceof \Exception.

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

 

[fawkes]

*смайл с запутанными глазами*

 

[fixxxer]

Кодом тогда как-то так (с поправкой на "не можем ловить ExceptionInterface" - BaseException вместо интерфейса):

abstract class BaseException extends \Exception {
   abstract public function getErrorLevel();
}
class ErrorException extends BaseException {
    public function getErrorLevel() { return 1; }
}
class FooException extends BaseException {
    public function getErrorLevel() { return $this->level; }
    public function getFoo() { return $this->foo; }
   ..........
}

соответственно если я делаю catch BaseException я ожидаю гарантированное наличие getErrorLevel, а вот если catch FooException - еще и getFoo.

 

[Вурдалак]

fixxxer, не-не-не. Суть моего вопроса зачем нужен интерфейс на этой стадии, когда методов ещё нет. Использование его невозможно (в благих целях и мотивировать это обратной совместимостью нельзя), почему бы не добавить интерфейс тогда, когда появится первый для него метод?

 

[fixxxer]

С твоей поправкой про невозможность ловить - я с тобой согласен. Я что-то совсем забыл про это.
Про пустой интерфейс тоже согласен