Весь смысл обработки ошибок сводится к трем путям
1. показать юзеру "ой все пропало, ты ничего не можешь с этим сделать".
При этом ты все равно можешь проверить тип ошибки, и если к примеру упала БД, или кончилось место на диске - можешь отправить СМС админу, но юзеру все равно показать 500 без подробностей.
2. показать юзеру сообщение с детализацией, типа "сломалось вот это вот, и ты можешь исправить вот так вот". Например: вы спросили наше API о погоде, но не указали какой город вас интересует, облом.
Правда сообщество склоняется к мнению, что это скорее не исключительная ситуация, а часть бизнес-логики приложения, и такие проверки должны писаться на не исключениях.
3. самостоятельно своим кодом разрулить ситуацию.
К примеру при попытке записать логфайл у тебя "нет доступа" и ты поймав это исключение тут же пытаешься сменить права на папку и записать лог повторно.
Или запрос по сети к внешнему сервису вернул ошибку, и твой код поймав исключение типа NetworkError не сразу падает, а делает парочку повторных запросов, и только при неудаче показывает ошибку.
Эти пути можно комбинировать, ведь при установке кодов вы сами решаете какая у вас ситуация - хотите ли вы просто отдать 500, или выплеснуть на пользователя немного подробностей, или разрулить своим кодом, если это возможно.
В ряде случаев хорошей практикой будет сгенеририровать уникальный номер, записать подробный дамп запроса ($_GET, $_POST, и stacktrace) и показать юзеру "произошла ошибка, код ошибки 1234567, сообщите этот номер в поддержку или попробуйте позже". Но опять же, только вам решать насколько оно вам нужно, и есть ли у вас ресурсы на подробное расследование таких случаев.
