Конечно, есть ряд случаев, когда этот оператор (@) можно применить, к примеру, с функциями по работе с файлами - если нет специальных прав по изменению файлов в конкретной директории, иными словами, стоит запрет, то, естественно, будут ошибки.
Было замечательное видео с конференции Devconf 2013 года - "Собачники против кинофобов", где Александр SamDark Макаров (один из главных мейнтенеров/разработчиков Yii фреймворка) и Романа Шевченко в форме шутливого поединка обсуждают этот вопрос. К сожалению, видео было на оф. сайте Defconf и безвозмездно потеряно, осталась только презентация - www.slideshare.net/lidiyamyalkina/c-37490142 .
А вообще, уж не знаю, как там в CMS, но во фреймворках существует механизм (костыль) по отлову ошибок, не исключений, в том числе, и фаталов, а там трава не расти - показывай пользователю или не показывай, а только записывай в лог. К слову, в PHP 7 многие ошибки переведены в разряд исключений, в 7.1 - эту работу продолжили, так что в будущем от этого механизма, думаю, можно будет отказаться.
> Ведь если бы оставили, и я бы смог поставить 5.4
Ну, как бы полная поддержка PHP 5.4 закончена в сентябре 2015-го, а 5.5 в 2016-ом - php.net/supported-versions.php, т.е. даже security-патчи не выпускают, потому уважаемый Ondrej (https://launchpad.net/~ondrej/) решил именно так, и это его право. Осталось только использовать старые LTS релизы той же Ubuntu, где нужная версия PHP есть из коробки или собирать из исходников. Потому в такой ситуации использование контейнеров - самое удобное и компромиссное решение.
Никита Кит: Подход с использование подавления ошибок (@) - крайне грязное решение. Так как ошибка "Method should not be called statically" является ошибкой E_STRICT, то, как вариант, попробуйте в php.ini прописать специальные декларации, а именно, исключить отлов ошибок такого типа:
Вот пример php.ini файла - https://github.com/romeOz/docker-apache-php/blob/m... . Аналогичные декларации можно прописать в php-скрипте, желательно в корне (в единой точки доступа к веб-приложению), обычно это index.php:
Уверен, в Битриксе где-нибудь они уже прописаны, потому стоит отыскать. Если вы используйте какую-нибудь IDE, то провести поиск по всему проекту проще простого, либо grep-ом:
grep -rHn "error_reporting" /to/path/app/
Указанные выше декларации используется, как раз-таки на production (боевом) сервере после разработки и тестирования проекта - негоже обыкновенному смертному видеть stack trace ошибок, в случае чего.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Было замечательное видео с конференции Devconf 2013 года - "Собачники против кинофобов", где Александр SamDark Макаров (один из главных мейнтенеров/разработчиков Yii фреймворка) и Романа Шевченко в форме шутливого поединка обсуждают этот вопрос. К сожалению, видео было на оф. сайте Defconf и безвозмездно потеряно, осталась только презентация - www.slideshare.net/lidiyamyalkina/c-37490142 .
А вообще, уж не знаю, как там в CMS, но во фреймворках существует механизм (костыль) по отлову ошибок, не исключений, в том числе, и фаталов, а там трава не расти - показывай пользователю или не показывай, а только записывай в лог. К слову, в PHP 7 многие ошибки переведены в разряд исключений, в 7.1 - эту работу продолжили, так что в будущем от этого механизма, думаю, можно будет отказаться.
> Ведь если бы оставили, и я бы смог поставить 5.4
Ну, как бы полная поддержка PHP 5.4 закончена в сентябре 2015-го, а 5.5 в 2016-ом - php.net/supported-versions.php, т.е. даже security-патчи не выпускают, потому уважаемый Ondrej (https://launchpad.net/~ondrej/) решил именно так, и это его право. Осталось только использовать старые LTS релизы той же Ubuntu, где нужная версия PHP есть из коробки или собирать из исходников. Потому в такой ситуации использование контейнеров - самое удобное и компромиссное решение.