Случается, когда вы пытаетесь получить доступ к объекту объекта, пока нет объекта.
Типичный пример для non-object notice будет
$users = json_decode('[{"name": "hakre"}]');
echo $users->name; # Notice: Trying to get property of non-object
В этом случае $users
представляет собой массив (а не объект), и он не имеет никаких свойств.
Это похоже для доступа к несуществующему индексу или ключу массива (см. Примечание: Undefined Index ).
Этот пример значительно упрощен. Чаще всего такое уведомление сигнализирует неконтролируемое возвращаемое значение, например. когда библиотека возвращает NULL
, если объект не существует или просто неожиданное значение, отличное от объекта (например, в результате Xpath, структуры JSON с непредвиденным форматом, XML с неожиданным форматом и т. д.), но код не проверяет такой условие.
Поскольку эти не-объекты часто обрабатываются дальше, часто возникает фатальная ошибка при вызове метода объекта для не-объекта (см.: Неустранимая ошибка: вызов члену function ... на не-объекте ), останавливая скрипт.
Его можно легко предотвратить, проверив условия ошибки и / или переменную, соответствующую ожиданию. Здесь такое уведомление с примером DOMXPath:
$result = $xpath->query("//*[@id='detail-sections']/div[1]");
$divText = $result->item(0)->nodeValue; # Notice: Trying to get property of non-object
Проблема заключается в доступе к свойству nodeValue
первого поля, пока он не был проверен, существует ли он или нет в $result
коллекция. Вместо этого он платит, чтобы сделать код более явным, назначив переменные объектам, на которых работает код:
$result = $xpath->query("//*[@id='detail-sections']/div[1]");
$div = $result->item(0);
$divText = "-/-";
if ($div) {
$divText = $div->nodeValue;
}
echo $divText;
Связанные ошибки:
спецификация JSON предлагает application/json
, и это, кажется, поддерживается IETF и реестр IANA .
<удар> По второму вопросу, я думаю, перестала ли обработка сообщений работать в некотором роде, необходимо возвратить ответ структурированной и стандартной погрешности как сообщение JSON; только если существует отказ передать сообщение к обработчику бэкендов, по некоторым причинам должен Вы рассматривать код Ошибки HTTP.
Обновление 27.06.2014 : дни, где клиенты (браузеры) только работали с 200 ответами, долго проходят, и преобладающий совет для УСПОКОИТЕЛЬНЫХ API состоит в том, чтобы использовать Коды ответа HTTP, подходящие для ответа, 2xx для успешных ответов (например, 201 Созданный для ПОМЕЩЕННОГО; 204 Никакого Содержания для НЕ УДАЛЯЕТ), и 4xx и 5xx для всех состояний ошибки, включая тех от самого API.
Я предпочитаю отвечать как с ошибкой HTTP, так и с полезной нагрузкой приложения.