E_NOTICE? == E_DEBUG, избегание isset () и @ с помощью более сложного error_handler

Какие лучшие способы существуют, чтобы избежать изобилия isset () в логике приложения и сохранить возможность видеть сообщения отладки (E_NOTICE) , когда требуется ?

Сначала предположение: E_NOTICE не является ошибкой, это неправильное название и на самом деле должно быть E_DEBUG. Однако, хотя это верно для неустановленных переменных (PHP по-прежнему является языком сценариев), некоторые функции файловой системы и т. Д. Также бросают их. Следовательно, желательно разработать с включенными E_NOTICE.

Однако не все уведомления об отладке полезны, поэтому « распространенная (неудачная) идиома PHP для вводит isset () и @ во всей логике приложения. Безусловно, существует множество допустимых вариантов использования isset / empty, но в целом он кажется синтаксической солью и может фактически препятствовать отладке.

Вот почему в настоящее время я использую букмарклет error_reporting и тупой переключатель включения / выключения:

// javascript:(function(){document.cookie=(document.cookie.match(/error_reporting=1/)?'error_reporting=0':'error_reporting=1')})()

if (($_SERVER["REMOTE_ADDR"] == "127.0.0.1")
    and $_COOKIE["error_reporting"])
{
    error_reporting(E_ALL|E_STRICT);
}
else {/* less */}

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

Но это тоже неудовлетворительно. Отсюда вопрос. Кто-нибудь использует или знает более сложный обработчик ошибок PHP. Я представляю что-то, что:

• выводит неотфильтрованные ошибки / предупреждения / уведомления (с абсолютным позиционированием CSS?)
• и еще много чего AJAX, чтобы разрешить проверку и подавление на стороне клиента
• , но также сохраняет список фильтрации ожидаемые и « одобренные » уведомления или предупреждения.

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

• В основном меня интересует управление предупреждениями / уведомлениями .
• Полное подавление E_NOTICE действительно нежелательно.
• E_NOTICES требуются . Просто их меньше. По умолчанию выделите те, которые могут мне небезразличны, а не ожидаемые.
• Если я буду работать без параметра? Order =, произойдет ожидаемое УВЕДОМЛЕНИЕ. Как и следовало ожидать, мне не нужно сообщать об этом более одного раза.
• Однако в режиме полной отладки я действительно хочу видеть присутствие неопределенных переменных через присутствие (или, что более интересно, отсутствие) указанных уведомлений об отладке. -> Я думаю, что они для этого. Избегание isset приводит к неявным операторам печати. ​​
• Также поймите, что это касается случаев использования, где подходит обычная семантика обработки форм PHP, а не областей приложения, где строгость является обязательной.

Ой, кто-нибудь, пожалуйста, помогите переписать это. Длительное объяснение не удается.