«Runn Me!» — говорит нам очередной фреймворк* на PHP. А слышится «Throw Me!». Часть 2

Судя по коду, правильнее так

try {
// ...
} catch (Exceptions $errors) {
  foreach ($errors as $error) {
    echo $error->getMessage();
  }
} catch (Exception $error) {
   echo $error->getMessage();
}

Т.к. Exceptions не наследуется от Exception

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

Однако мы решили, что возможный профит от такого подхода во много раз превышает минусы, которые можно от него ожидать.

tl;dr Я так и не понял, вы вроде бы за type safety (коллекции, нул объекты) и вроде как и нет (неявное возвращение значений при помощи throw вместо явного).

получает особую суперспособность: его можно «выбросить» (throw).

Это в свою очередь порождает сайд эффекты. С великой силой приходит великая ответственность.

Имплементация интерфейса JsonSerializable неспроста добавлена сразу же в Runn\Core\Exception: это явный задел на будущее

Что делать если я захочу в debug режиме добавлять помимо кода ошибки и описания еще и стэктрэйс? Налицо нарушение open/close принципа. Да, это просто, но намного проще будет сделать так:

class JsonExceptionFormatter implements ExceptionFormatter
{
    private $shouldIncludeDebugInfo;

    public function __construct(bool $debug)
    {
        $this->shouldIncludeDebugInfo = $debug;
    }

    public function format(Throwable $e)
    {
         return new JsonResponse(array_merge(
              [
                  'code' => $e->getCode(),
                  'message'
              ],
              $this->debugInfo(),
         )
    }

    private function debugInfo(\Throwable $exception): array
    {
        if (!$this->shouldIncludeDebugInfo) return [];

        return [
            'trace' => $e->getTrace(),
        ];
    }
}

Профит:

• разделение ответственности. Мы не помещаем логику форматирования данных в данные.
• Универсально. Мы можем сделать кучу разных форматтеров и выбирать их исходя из настроек или вообще через content negotiation.

Это мультиисключение:
механизм валидации, предусмотренный в стандартных объектах «Runn Me!».

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

Сравним запись:

try {
    $validator->validate($data);
} catch (Exceptions $validationErrors)
{
    $this->handleValidationErrors($validationErrors);
}

// vs

$errors = $validator->validate($data, $rules);

if ($errors->count() !== 0)
    $this->handleValidationErrors();

профит:

• валидатор становится чистым. Он получает данные на вход и возвращает результат. Отсутствуют сайд эффекты.
• такая же типизированная коллекция ошибок как и у вас, но без оверхэда и которая представляет собой дерево ошибок, в соответствии с иерархии валидируемых данных.
• даже ваш выше приведенный пример с JsonSerializable уже не так удобен. Моим клиентам удобен такой формат:

{
    "status_code": 422,
    "message": "Please check your data",
    "violations": [
         {"path": "/foo/bar", "message": "Value should not be blank"},
         {"path": "/foo/email", "message": "Invalid email address"}
    ]
}

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

Однако мы решили, что возможный профит от такого подхода во много раз превышает минусы, которые можно от него ожидать.

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

Определили метод, он получает на вход то значение, которое вы намереваетесь присвоить свойству

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

перейдем к теме комплексных (очень хочется произнести это слово с ударением на «е»: «комплЕксных») объектов.

Вы выкинули в мусорку инкапсуляцию, о каких объектах вы говорите? Это структуры данных, property bags. Тупые и бесполезные.

оповещения нас о том, что некоторые обязательные поля оказались неустановленными в конструкторе объекта.

Поздравляю. Вы переизобрели Design by Contract/AOP. Можно просто повесить на класс описание инвариантов и трекать все при помощи какого-нибудь goaop. Выйдет тоже что и у вас но за счет прокси объектов а не наследования.