php как вернуть ошибку
JQuery — AJAX, как вернуть сообщение об ошибке из файла PHP
Как вы, наверное, поняли, есть некоторый не важный код, который я пропустил. Я надеюсь, что кто-то может понять и помочь мне! Спасибо!
Решение
Вот как именно это можно сделать:
В ВАШЕМ ФАЙЛЕ PHP:
У ВАШЕЙ СТОРОНЫ JQuery AJAX:
Другие решения
показать / скрыть ошибку div, основанную на успехе / неудаче, возвращенной серверным скриптом.
HTML-код:
JS CODE:
Примечание об устаревании: обратные вызовы jqXHR.success (), jqXHR.error () и jqXHR.complete () устарели с версии jQuery 1.8. Чтобы подготовить ваш код для их возможного удаления, используйте взамен jqXHR.done (), jqXHR.fail () и jqXHR.always ().
В свой улов вы могли бы положить
Попробуйте использовать следующий фрагмент:
Используйте функцию PHP json_encode для массива. Затем массив будет представлен в javascript как объект JSON (аргумент / параметр ‘response’).
Первый, Вы должны сообщить Javascript, что произошла ошибка на стороне сервера
второй, вам нужно обработать ошибку при загрузке JSON
Это пример запросов POST, касающихся конфиденциальных данных формы (или данных, которые вы, например, будете связывать с запросом UPDATE или INSERT). Я включил функцию serialize () для обработки полей имени из формы на вашем бэкэнде. Я также удалил передачу данных через функцию успеха. Вы не хотите этого делать, когда имеете дело с конфиденциальными данными или данными, которые вы не планируете отображать. Я решил опубликовать это здесь, так как эта тема возникла, когда я искал, как сделать POST с AJAX, который возвращает ошибку.
Говоря о возврате ошибки, вы захотите сделать это сейчас, когда PHP снова обновился. Я также рекомендую прочитать через 5.4+ документов.
Я добавил функцию die (), чтобы после запроса 404 ничего не происходило.
Обработка критических ошибок в PHP
В статье описан функционал, который доступен в PHP (актуально для 5.3.х) для обработки ошибок всех типов, включая ошибки интерпретации кода (E_ERROR, E_PARSE, E_WARNING, etc). Эта обработка поможет вам для управляемого отображения страницы в случае возникновения таких проблем. В статье присутствует множество описаний и рабочих примеров(архитектуры) для того, что бы сразу воспользоваться в своем программном продукте. В конце концов, ну немного сломали сайт, ну надо же, об этом сообщить поисковику с заголовком 4хх или 5хх и повеселить пользователя, вместо возврата белого экрана (или что хуже экрана со священной информацией, для хакеров) с ответом 200 Ok.
Если заинтересовались, то подробности под катом…
Причины использования
Пользователю/поисковику, требуется внятно ответить, что на сервере проблемы. Без использования определенного фен-шуя, этого добиться достаточно трудно, а порой невозможно. Тут я проливаю свет на все это, ну и себе заметочку оставляю, так как еще неделю назад я не знал за что взяться, и, наверное, многие новички тоже будут обескуражены.
Описания функций
Данный функционал доступен в PHP для того, что бы обрабатывать ошибки и контролировать вывод. Вот описание их вкусностей и недостатков. Документацию я приводить не буду, я только сошлюсь её страницы и опишу свое мнение. Все что будет приведено это только малая доля, ссылки на соответствующие разделы документации я приведу в конце статьи. Итак встречаем:
— Контроль некритических ошибок: замечания, предупреждения, пользовательские ошибки. В общем все то, что не завершает интерпретацию аварийно.
set_error_handler — Задает определенный пользователем обработчик ошибок.
Нужен для того, что бы писать в лог все такие ошибки. Если её не задать, то в лог это не пишется, а мне вот всегда хочется узнать при каких боевых ситуациях могут вызываться замечания и предупреждения. То есть позволяет автоматически тестировать продукт пользователем и он даже не будет замечать этого.
Если функция не задана, то PHP лишь пытается вывести данные на экран, а если ему и это не дают, то вообще никаких признаков жизни от этих типов ошибок не возникает.
— Контроль, исключений: является ошибкой типа E_ERROR.
set_exception_handler — Задает пользовательский обработчик исключений
Ну не знаю, зачем это вообще было придумано, когда есть то, что описано ниже и просто обработка ошибки типа Exception. Так что сообщаю что оно просто существует. Она перехватывает критическую ошибку «исключение» и позволяет что-то с ней делать. В любом случае скрипт завершается. Её работы по умолчанию лично для меня достаточно (пишет в логи, пытается вывести на экран). Я бы её вообще не переопределял, а то придется в логи о случившимся исключении самому писать.
— Функции контроля вывода: Тут я опишу 3 функции, которые следует знать по разным причинам. Например, для проблем производительности или для проблем вывода заголовков. В нашем случае требуется выводить заголовки ошибок.
ob_start — Включение буферизации вывода
ob_flush — Сброс (отправка) буфера вывода
ob_end_clean — Очищает (стирает) буфер вывода и отключает буферизацию вывода
Если вкратце, то данные функции позволяют записывать все данные выводимые через echo в некий буфер. Это функционал позволяют отправлять заголовки в любой части кода, а так же многие другие вещи, темы которых не относится к данной статье. А если вдруг случилась беда. То можно сбрасывать весь буфер и весь стек (об этом не в этой статье), писать заголовок ошибки и выводить уведомление пользователю.
— Получение последней произошедшей ошибки: её надо использовать вместе с другими перехватывающими функциями, которые тут описаны.
error_get_last — Получение информации о последней произошедшей ошибке
С помощью нее, возможно вернуть последнюю ошибку. Ей очень удобно ловить критические ошибки и код становится оптимальным (появилась с 5.2.х если что).
Многие Объектно Ориентированные люди обрадуются
Что все вышеизложенные функции можно зарегистрировать даже на методы классов, а также, наверняка, на статические методы классов по той же схеме. Правда способ очень не очевиден для глаза обычного не PHP программиста.
Параметр handler требуется задать через массив, с элементами «название класса|объекта», «метод объекта». Устанавливаемый метод обязательно должен быть public. Пример для функции set_error_handler:
Рабочий пример
Пример работы, архитектура класса для универсального и полного контроля ошибок. Я исследовал этот вопрос очень досконально и составил гибридный метод, из ответов на заданные мною вопросы.
Условия
Есть файл с кодом, который запускается первым или перед кодом в котоом может появиться ошибка и этот файл и все файлы до него 100% отлаженные с невозможностью появления ошибки. Вот такое вот условие, что бы было проще — без ошибок до того пока не пройдут все регистрации вышеизложенных функций. В данном файле описаны данные методики контроля ошибок в комплексе. Контролируется буфер, если ошибка, то сбросить буфер и вывести ошибку.
Код с комментариями
От себя добавлю, что код не тестировал, так как это упрощенная схема того, что у меня в коде, замечания принимаются
Ссылки
Разделы документации
Другая полезная информация
Спасибо за внимание.
UPD: По советам из комментариев, дополнил класс ErrorSupervisor новой функциональностью, исправил пару заблуждений, добавил дополнительную интересную информацию по теме, немного отладил код
UPD2 Внимание: Товарищ по PHP-разуму написал хорошую статью про битовые операции в PHP как раз к теме данной статьи, советую почитать. Эти знания позволяют более элегантно писать код. Менять текст данной статьи уже не стал для того, что бы сохранился смысл.
Что именно и когда возвращать пользователю в PHP в случае ошибки?
Меня интересует вопрос о возврате сообщения или ошибки в PHP. В каких случаях показывать 500 ошибку пользователю с небольшой информацией о случившемся, а когда лучше выводить текст ошибки.
То есть вопрос заключается в том, чтобы четко разделить вывод Exception и его сообщения клиенту.
Скажем, что сейчас есть несколько вариантов развития событий:
В случае серьезных ошибок на стороне сервера (закрыт доступ на создание директорий, ошибка подключения в серверу отправки почты и прочие) показывать страницу 500 ошибки с текстом.
В случае ошибок со стороны пользователя (формат файла не прошел проверку, запрашиваемые данные не найдены, отсутствует папка или файл для работы и прочие) показывать сообщение (вернуть текст ошибки).
В случае любых ошибок возвращать текст ошибки или «не удалось», а сами ошибки логировать.
То, что я делаю сейчас можно назвать библиотекой разработки (может и микро-фреймворк). В ней я хочу реализовать подход работы с ошибками и не могу точно определить, как это делать лучше.
Конкретно вопрос возник тогда, когда я разобрался, что я буду выводить в качестве результата работы хелпера по работе с файлами, но не смог решить, что именно возвращать при закрытом доступе при рабоет с папками.
2 ответа 2
Хороший вопрос, и, на самом деле, очень простой.
Я не вижу здесь трех вариантов развития событий. Если присмотреться, то пункты 1 и 3 это одно и то же. А пункт 2 ошибкой вообще не является. То есть в результате у нас есть один-единственный сценарий для обработки ошибок в приложении: просто пишем один маленький error/exception handler, который и занимается тем что показывает юзеру 500 страницу с извинениями, а саму ошибку пишет в лог.
http_response_code
(PHP 5 >= 5.4.0, PHP 7, PHP 8)
http_response_code — Получает или устанавливает код ответа HTTP
Описание
Получает или задаёт коды ответов HTTP.
Список параметров
Возвращаемые значения
Примеры
Пример #1 Использование http_response_code() в окружении веб-сервера
// Берём текущий код и устанавливаем новый
var_dump ( http_response_code ( 404 ));
// Берём новый код
var_dump ( http_response_code ());
?>
Результат выполнения данного примера:
Пример #2 Использование http_response_code() в CLI
// Берём текущий код по умолчанию
var_dump ( http_response_code ());
// Устанавливаем код
var_dump ( http_response_code ( 201 ));
// Берём новый код
var_dump ( http_response_code ());
?>
Результат выполнения данного примера:
Смотрите также
User Contributed Notes 18 notes
If your version of PHP does not include this function:
For reference the error codes I got from PHP’s source code:
And how the current http header is sent, with the variables it uses:
Note that you can NOT set arbitrary response codes with this function, only those that are known to PHP (or the SAPI PHP is running on).
The following codes currently work as expected (with PHP running as Apache module):
200 – 208, 226
300 – 305, 307, 308
400 – 417, 422 – 424, 426, 428 – 429, 431
500 – 508, 510 – 511
Codes 0, 100, 101, and 102 will be sent as «200 OK».
Everything else will result in «500 Internal Server Error».
If you want to send responses with a freestyle status line, you need to use the `header()` function:
When setting the response code to non-standard ones like 420, Apache outputs 500 Internal Server Error.
This happens when using header(0,0,420) and http_response_code(420).
Use header(‘HTTP/1.1 420 Enhance Your Calm’) instead.
Note that the response code in the string IS interpreted and used in the access log and output via http_response_code().
You can also create a enum by extending the SplEnum class.
/** HTTP status codes */
class HttpStatusCode extends SplEnum <
const __default = self :: OK ;
const SWITCHING_PROTOCOLS = 101 ;
const OK = 200 ;
const CREATED = 201 ;
const ACCEPTED = 202 ;
const NONAUTHORITATIVE_INFORMATION = 203 ;
const NO_CONTENT = 204 ;
const RESET_CONTENT = 205 ;
const PARTIAL_CONTENT = 206 ;
const MULTIPLE_CHOICES = 300 ;
const MOVED_PERMANENTLY = 301 ;
const MOVED_TEMPORARILY = 302 ;
const SEE_OTHER = 303 ;
const NOT_MODIFIED = 304 ;
const USE_PROXY = 305 ;
const BAD_REQUEST = 400 ;
const UNAUTHORIZED = 401 ;
const PAYMENT_REQUIRED = 402 ;
const FORBIDDEN = 403 ;
const NOT_FOUND = 404 ;
const METHOD_NOT_ALLOWED = 405 ;
const NOT_ACCEPTABLE = 406 ;
const PROXY_AUTHENTICATION_REQUIRED = 407 ;
const REQUEST_TIMEOUT = 408 ;
const CONFLICT = 408 ;
const GONE = 410 ;
const LENGTH_REQUIRED = 411 ;
const PRECONDITION_FAILED = 412 ;
const REQUEST_ENTITY_TOO_LARGE = 413 ;
const REQUESTURI_TOO_LARGE = 414 ;
const UNSUPPORTED_MEDIA_TYPE = 415 ;
const REQUESTED_RANGE_NOT_SATISFIABLE = 416 ;
const EXPECTATION_FAILED = 417 ;
const IM_A_TEAPOT = 418 ;
const INTERNAL_SERVER_ERROR = 500 ;
const NOT_IMPLEMENTED = 501 ;
const BAD_GATEWAY = 502 ;
const SERVICE_UNAVAILABLE = 503 ;
const GATEWAY_TIMEOUT = 504 ;
const HTTP_VERSION_NOT_SUPPORTED = 505 ;
>
Status codes as an array:
The note above from «Anonymous» is wrong. I’m running this behind the AWS Elastic Loadbalancer and trying the header(‘:’.$error_code. ) method mentioned above is treated as invalid HTTP.
The documentation for the header() function has the right way to implement this if you’re still on ( «HTTP/1.0 404 Not Found» );
?>
At least on my side with php-fpm and nginx this method does not change the text in the response, only the code.
// HTTP/1.1 404 Not Found
http_response_code ( 404 );
?>
The resulting response is HTTP/1.1 404 OK
http_response_code() does not actually send HTTP headers, it only prepares the header list to be sent later on.
So you can call http_reponse_code() to set, get and reset the HTTP response code before it gets sent.
http_response_code(500); // set the code
var_dump(headers_sent()); // check if headers are sent
http_response_code(200); // avoid a default browser page
http_response_code is basically a shorthand way of writing a http status header, with the added bonus that PHP will work out a suitable Reason Phrase to provide by matching your response code to one of the values in an enumeration it maintains within php-src/main/http_status_codes.h. Note that this means your response code must match a response code that PHP knows about. You can’t create your own response codes using this method, however you can using the header method.
1. Using http_response_code will cause PHP to match and apply a Reason Phrase from a list of Reason Phrases that are hard-coded into the PHP source code.
2. Because of point 1 above, if you use http_response_code you must set a code that PHP knows about. You can’t set your own custom code, however you can set a custom code (and Reason Phrase) if you use the header method.
It’s not mentioned explicitly, but the return value when SETTING, is the OLD status code.
e.g.
= http_response_code ();
$b = http_response_code ( 202 );
$c = http_response_code ();
if you need a response code not supported by http_response_code(), such as WebDAV / RFC4918’s «HTTP 507 Insufficient Storage», try:
HTTP/1.1 507 Insufficient Storage
On PHP 5.3 version, If you want to set HTTP response code. You can try this type of below trick 🙂
Обработка ошибок в PHP
Обработка ошибок с помощью trigger_error() и set_error_handler()
PHP предоставляет прекрасную возможность контролировать возникающие ошибки. Здесь мы поговорим о том, как обработать ошибку — сообщить (или не сообщить) о происшествии пользователю, в случае необходимости — сообщить администратору с помощью электронной почты, записать информацию о происшествии в log-файл.
Итак, для начала давайте определимся, что такое ошибки в PHP.
PHP поддерживает следующие уровни ошибок:
E_ERROR
E_WARNING
E_PARSE
E_NOTICE
E_CORE_ERROR
E_CORE_WARNING
E_COMPILE_ERROR
E_COMPILE_WARNING
E_USER_ERROR
E_USER_WARNING
E_USER_NOTICE
E_ALL
E_STRICT
На самом деле — это просто константы, которые используются для определения уровня обработки ошибок, построения бит-маски. Константы имеют «говорящие» имена. Глядя на константу — мы можем сказать, что ошибка уровня E_PARSE возникает в случае синтаксической ошибки, E_NOTICE — это напоминание программисту о нарушении «хорошего стиля» программирования на PHP.
Когда соединение с базой данных MySQL (или другой) завершается неудачей — интерпретатор PHP сообщает об ошибке уровня E_WARNING
php_flag display_errors on
php_value error_reporting «E_ALL &
Это означает, что сообщения об ошибках будут показываться, причем всех уровней, кроме E_NOTICE
Когда программист допускает синтаксическую ошибку — интерпретатор PHP сообщает об ошибке уровня E_PARSE
Parse error: parse error, unexpected ‘(‘, expecting T_STRING in /home/mysite/index.php on line 150
Но самые интересные для нас уровни ошибок — E_USER_ERROR и E_USER_WARNING. Как становится понятно из названия — это уровни ошибок, которые может устанавливать пользователь. Для этого существует функция trigger_error() — с её помощью, Вы можете сообщать пользователю о происшествии так, как это делает PHP.
Как известно из руководства по PHP — функция trigger_error() принимает два параметра.
void trigger_error ( string error_msg [, int error_type])
Первый параметр — текстовое сообщение об ошибке, например «файл не найден». Второй параметр — определяет уровень ошибки. Функция trigger_error() работает только с семейством ошибок E_USER — это значит, что вы можете установить ошибку уровня E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE и не можете установить ошибку уровня E_WARNING. Второй параметр является не обязательным, и по умолчанию принимает значение E_USER_NOTICE.
Допустим, наши данные для ленты новостей хранятся в файле news.txt, и если файл не найден — необходимо сообщить об ошибке. Текст программы будет выглядеть примерно так:
if (!file_exists(‘/home/mysite/news.txt’)) <
trigger_error(‘News file not found’);
>
В результате интерпретатор PHP сообщит об ошибке уровня E_USER_NOTICE
php_value log_errors «1»
php_value log_errors_max_len «1024»
php_value error_log «/home/mysite/my.log»
То в файл /home/mysite/my.log автоматически будет добавлена запись о происшествии.
[23-Mar-2004 13:52:03] PHP Notice: News file not found in /home/mysite/index.php on line 47
Далее, с помощью функции set_error_handler() мы можем установить свой собственный обработчик ошибок возникающих во время выполнения PHP скрипта.
Как известно из мануала — в PHP 4 функция принимает один единственный строковый параметр — имя функции, которая будет выполняться каждый раз, когда происходит ошибка. PHP 5 даёт возможность установить ещё один параметр — тип ошибок которые будут обрабатываться с помощью нашего обработчика. Функция возвращает строку — имя функции обработчика, который был установлен до этого момента.
string set_error_handler ( callback error_handler [, int error_types])
set_error_handler («my_error_handler»);
Пользовательская функция, которая будет обрабатывать ошибки, может принимать следующие входные параметры:
— код уровня ошибки
— строковая интерпретация ошибки
— имя файла, в котором произошла ошибка
— строка, в которой произошла ошибка
Следует так же заметить, что эта функция не может обрабатывать ошибки уровней E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING
Это связанно с тем, что ошибки перечисленных уровней происходят до того, как интерпретатор получает информацию о пользовательском обработчике ошибок.
Итак, объявляем нашу функцию
Замечание: каждый более-менее объемный скрипт обычно разделяется на несколько файлов для удобства работы с ним. Как организовывать модульность программы — тема отдельно разговора. Сейчас же, я хочу лишь посоветовать выделять общие настройки в отдельный файл, который будет подключаться в начале программы с помощью инструкции include, либо с помощью директивы auto_prepend_file. В этот файл можно поместит и наш обработчик. Установка обработчика ошибок должна осуществится как можно ближе к началу программы, желательно в самом начале.
Для того чтобы убедится что это действительно работает — создадим новый PHP файл, и попробуем запустить его
Содержимое файла myerrortest.php
Результат обработки данного файла будет таким:
Произошла ошибка News file not found (1024)
/home/mysite/myerrortest.php (12)
Теперь у нас есть функция, которая получает данные обо всех происходящих ошибках. Подумаем, как мы можем это использовать.
Будем обрабатывать ошибки уровней
E_ERROR
E_WARNING
E_NOTICE
E_USER_ERROR
E_USER_NOTICE
Первые три ошибки в хорошей законченной программе не должны происходить вообще, поэтому о них мы будем только сообщать пользователю выводом текста ошибки на экран. Так можно работать, пока скрипт в состоянии разработки, затем сообщения о них можно либо отключить, либо записывать в log-файл.
Что касается остальных двух — как Вы уже догадались — они могу там пригодиться. Мы сами будем вызывать ошибки этих уровней в случае необходимости. Допустим — ошибки уровня E_USER_ERROR — будем вызывать в случае, когда сообщение об ошибке должно попасть в log-файл и быть отправлено на e-mail администратору (например — ошибка при выполнении SQL запроса, или отсутствии парв доступа к необходимому файлу). Ошибки уровня E_USER_NOTICE будут вызываться при возникновении «лёгких» ошибок (например — пользователь некорректно заполнил форму, или запросил из базы несуществующую запись).
Теперь наша функция обработки ошибок будет выглядеть примерно так:
Для того чтобы пример заработал — просто скопируйте в PHP-файл три предыдущих блока кода. Не забудьте установить права доступа на log-файл 777 для того чтобы скрипт мог с ним работать, прописать правильные пути и указать свой e-mail. Вы можете включить режим отладки установкой переменной DEBUG в 1.
Это довольно простой пример, тему можно развивать.