Каковы общие /лучшие практики для фреймворков, обрабатывающих стандартные сторонние исключения?

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

ORM-ность этого компонента сильно абстрагирует запросы до такой степени, что разработчику не нужно знать какой-либо SQL или даже знать терминологию SQL. Основной движущей силой этого является мой опыт работы в качестве администратора DBA /BIDev, где я стонал над многими плохо сконструированными запросами со стороны любителей SQL, которые запутали вещи, а не взяли самый простой самый прямой подход. В качестве примера следующий код: r SELECT ... FOR UPDATE из user, где username - 'jennifer':

$userFilter = $userRepository->createBlank();
$userFilter->username()->identifyValue('jennifer');
$userFilter->lockForUpdate();
$user = $userRepository->retrieve($userFilter);

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

  

SQLSTATE [0A000]: функция не поддерживается: 7 ОШИБКА: ДЛЯ ОБНОВЛЕНИЯ нет   разрешено с помощью функций окна Сбой запроса: SELECT * FROM "myView"   WHERE «ID» =: fi_ID__ix0 ДЛЯ ОБНОВЛЕНИЯ;

Оказывается, что в представлении myView содержится столбец, который генерируется функцией OLAP /window (т.е. ROW_NUMBER() OVER(PARTITION BY...), что означает, что представление не может быть выбрано для обновления. Ошибка была создана PostgreSQL, полностью легитимна и, естественно, отвечает на эту недействительную операцию.

Что мне интересно, каковы общие /общепринятые способы, с помощью которых обращаются с такими сторонними проблемами? Выдайте сообщение об ошибке дословно и дайте разработчику понять это или попытайтесь добавить значение в сообщение, предложив общие проблемы или возможности расследования?

3 голоса | спросил e_i_pi 27 Jpm1000000pmSat, 27 Jan 2018 12:40:21 +030018 2018, 12:40:21

2 ответа


2

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

  

... это происходит из моего опыта как DBA /BIDev, где я стонал над многими плохо сконструированными запросами у любителей SQL, которые запутали вещи ...

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

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

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

ответил Bogdan 27 Jpm1000000pmSat, 27 Jan 2018 15:35:09 +030018 2018, 15:35:09
1
  

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

Оба варианта кажутся точными. Я бы основывал свое решение на информации, предоставленной поставщиком библиотеки.

Некоторые библиотеки (в целом созданные для некоммерческих целей) очень «спартанские» в деталях и документации. Мы все видели (время от времени) сообщения об ошибках, такие как:

  

Ошибка. Неверные данные

О, мужик! Что, черт возьми, это значит? Я отправил неверные данные? Неверные форматы? Неправильные диапазоны? Что пошло не так?!?!

Если вы можете скрыть такую ​​мерзость, если вы можете дать больше контекста и обратной связи, разработчики оценят это. Много. И все остальные будут вовлечены в проект.

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

PostgreSQL уже предоставляет достаточную информацию для разработчиков для исследования. Например, начиная с поиска, что означает SQLSTATE[0A000]. Это код ошибки и, вероятно, он где-то документирован . Итак, кто бы ни построил драйвер для PostgreSQL в PHP, не решился добавить одну кому в сообщения об ошибках. Не нужно! И так же кто-то строит фреймворк поверх этого драйвера.

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

  

Что мне интересно, каковы общие /общепринятые способы, которые   frameworks обрабатывают сторонние проблемы, подобные этому?

Каждая структура отслеживает ее опыт разработки . Вот в чем все рамки. Различные рамки могут подходить к одной и той же проблеме с разных сторон.

Итак, мне было бы все равно, о чем другие структуры. Я хотел бы сосредоточиться на опыте развития , который я хочу дать. Как я хочу, чтобы разработчики чувствовали себя с моей каркасом? Если бы я нашел другие фреймворки, которые опыт разработки и мои аналогичны, я бы принял к сведению, но я бы не принял их подход как способ пойти. Еще один подход, который я мог бы принять.

Вам может быть интересно

Связанные вопросы

ответил Laiv 27 Jpm1000000pmSat, 27 Jan 2018 15:52:51 +030018 2018, 15:52:51

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132