Должны ли логи оставаться чистыми?

Question

[WebDev]

У меня проект на Laravel.
Каждое утро я начинаю с того, что просматриваю файлы storage/logs/laravel-xxxx-xx-xx.log.
Очень часто там "ненастоящие" ошибки, например ошибка, что запись уже существует в БД (unique key).
Ошибку вызывает вот такой код:

$email = request()->input('email');
/*...*/
User::create(['email' => $email]);

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

$email = request()->input('email');
/*...*/

try {
User::create(['email' => $email]);
} catch (\Exception $e) {}

Но что если ошибка не в дублировании уникального ключа, а в чем-то еще? Я об этом не узнаю.
Как вы обрабатываете ошибки?
Должны ли логи всегда быть чистыми?

Comments

[Arman]

а пользователь видит 500 ошибку в таком случаи? почему нет проверки есть такая почта в БД или нет на уровне валидации?

[WebDev]

Arman, Нет, это АПИ. Пользователь шлёт аякс запрос и видит, что "что-то пошло не так, повторите попытку"

[jazzus]

WebDev, нужно валидировать и возвращать, что емейл уже зарегистрирован. 500 ошибок быть не должно

Answer 1

[Daria Motorina]

Лучше переписать код так, чтобы "ненастоящие" ошибки не возникали, штатные ситуации хендлить, нештатные ловить в логах. Лишние логи это нездоровая ситуация для долгоиграющего проекта.

Comments

[WebDev]

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

[Daria Motorina]

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

[WebDev]

Daria Motorina, Но ведь вместо проверки можно обернуть в try-catch и в catch анализировать ошибку.

[Daria Motorina]

WebDev, можно, но это не имеет смысла для проверки на уникальность - сценарии 'insert-or-update', 'select-or-create' встречаются повсеместно. Если у Вас нет четких причин экономить на этом запросе, то Вам нет смысла его не добавлять. Try-catch нужен для нештатных ситуаций, на которые Вы не можете повлиять при нормальных обстоятельствах. Это не значит, что try-catch тут не нужен, это значит, что не надо писать 3-4 catch, когда это решается гораздо проще.

[WebDev]

Daria Motorina, Смотрите, вы предлагаете так:

$email = request()->input('email');

$exists = User::where('email', $email)->exists();

if ($exists) {
    return 'красивое сообщение об ошибке';
}

User::create(['email' => $email]);

Я предлагаю так:

$email = request()->input('email');

try {
    User::create(['email' => $email]);
} catch (\Exception $e) {
    if ((int)$e->getCode() === 23000) {
        return 'красивое сообщение об ошибке'; 
    } else {
        Log::error($e);
    }
}

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

[Daria Motorina]

WebDev, я не отрицаю такой вариант, но тогда надо хендлить более четко - ловить именно тот эксепшен, который падает при нарушении уникальности, а не глобальный \Exception, и завернуть 23000 в константу

[jazzus]

WebDev, https://laravel.com/docs/5.8/validation

[NubasLol]

jazzus, он не хочет длеать лишние запросы на валидацию

[jazzus]

NubasLol, я по поводу этого
User::where('email', $email)->exists();
И смысла не использовать валидацию нет. для приложения эти запросы пшик, зато будет офигенный с тз поддержки form request

[NubasLol]

jazzus, ну какая разница, заапросы все равно лишние будут при валидации.

Если важно с экономить на запросе, можно ловить ошибку.

Ну пгнятно что с точки зрения читаемости кода это фигня, да и вообще тогда фреймворки фигня)И php)

[jazzus]

NubasLol, можно и из шаблона запросы делать я такое видел неоднократно. Открывают тег php и херачат логику в blade вместе с sql запросами. Или валидацию, как в примере автора выше. Form request задуман Ларавелей специально для валидации реквеста, а его не дураки проектировали. Тем более, что данные запросы и за запросы считать нельзя тк. несерьезно. вообще мне сложно судить т.к. я на Ларавеле учился и мыслю его методами изначально)

[NubasLol]

jazzus, Ну суть в том, что бд и так кинет исключение, нет смысла првоерять на uniq)Ну это тоже по мне экономия на спичках

Answer 2

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

Чтобы этого не было, мне нужно обернуть создание записи в try-catch

Ну или проверять перед попыткой вставки и отдавать пользователю адекватное сообщение.

Comments

[WebDev]

Я всегда не понимал зачем делать проверку, если мы на уровне БД сделали ограничение? Объясните, пожалуйста.
Это же дополнительная нагрузка, еще один запрос. Я ведь вместо этого могу в catch смотреть сообщение об ошибке и, если это дублирование уникального поля", то отдавать пользователю адекватное сообщение.

Answer 3

[Vitsliputsli]

Вы предлагаете проверять перед каждым созданием наличие такой записи?

У вас это и так происходит, иначе бы не было ошибки. Если вам действительно все равно на недобавившиеся строки, тогда скажите об этом СУБД, on conflict do nothing, или что-то в этом роде в зависимости от СУБД.
Но почему-то мне кажется, что ваши пользователи не согласятся с такой логикой.