Проверка типов: is<T>() и as<T>()

Сосед по даче обновил прошивку своего узла — и моя поливалка перестала переключать режимы. Пакет выглядел целым: {"mode":1,"temp":21.4}. Ключ mode на месте, containsKey радостно отвечал «есть», а скетч ждал строку "auto" — и чтение в const char* возвращало пустоту. Число в строку не превращается: поменялся тип, а не наличие. Ключ и значение — разные сущности, и проверять их надо разными вопросами; containsKey на тот день отвечал честно на вопрос, который я не задавал.

Экономика проверки дешёвая: две строки кода на поле против часа в журналах после чужого обновления. Прошивки серверов и соседних узлов меняются без предупреждений — я это проходил трижды: режим стал числом, давление стало строкой, счётчик переехал в другой ключ. Каждый раз разбор без проверок отвечал одинаково: молчаливый ноль на экране при честном 200 от сети. Guarding — не паранойя, а страховка с точной ценой: сколько рискованных полей — столько пар проверок, и ни одной больше. Считается это честно: пять полей чужого пакета — пять пар, десять строк кода, и больше ничего.

Инструменты проверки отвечают на три разных вопроса, и мы уже сравнивали два из них в уроке про чтение полей: containsKey спрашивает «был ли ключ в пакете», isNull — «есть ли пригодное значение». Третий вопрос задаёт is<T>(): «можно ли это прочитать как T?». is<float>() на целом 18 даст истину — целое читается как 18.00 без потерь; is<int>() на 21.4 в шестой версии библиотеки — ложь: дробь в целое без потерь не сворачивается. is<bool>() истинно только для настоящих true и false, is<const char*>() — для строк. Типовые сюрпризы с кавычками и null мы перечислили в уроке про типы данных — здесь речь о том, как строить защиту, когда тип поля заранее не гарантирован.

Чтение float t = doc["temp"]; — это неявный вызов as<float>(): библиотека приводит значение к типу слева по тем же правилам, что мы разбирали в уроке про типы переменных. При несовместимости — строка вместо числа, null, отсутствие ключа — приведение тихо даёт ноль или пустоту. Явная форма as<T>() даёт тот же ноль; выигрыш не в механике, а в управлении: явный as<T>() принято звать после проверки is<T>(), и тогда ноль появляется только там, где вы его действительно пропустили. Строка с is перед as объявляет каждому читающему: здесь тип не гарантирован.

Паттерн guarding, который я применяю к чужим API и чужим прошивкам, — три ветки. Первая: поле есть и это число — читать и работать. Вторая: поле есть, но строка — конвертировать atof, если строка числовая, и писать в лог, если нет. Третья: поля нет вовсе — запасное поведение и отметка в журнале. Своему протоколу между двумя моими платами такую броню я не вешаю: хватает containsKey, и код остаётся тонким. Чужому API — всегда: прошивки серверов меняются без предупреждений, и guarded разбор переживает чужое обновление молча, а без проверок — с нулями на экране. И это была не гипотеза: поливалка четыре дня поливала по умолчанию, пока я не распечатал чужой пакет.

Пара слов о строгости проверок. В шестой версии is<int>() на 21.4 отвечает ложью; седьмая проверяет мягче — скорее всего, разрешит чтение дроби в целое. Полагаться на конвертацию строк в числа я не советую ни в одной версии: просите сервер слать числа, а строку обрабатывайте явно через atof, когда она пришла. Если в проекте есть спорное поле — проверьте поведение is на своей версии один раз на столе, запишите результат в комментарий рядом с разбором, и спор закрыт навсегда.

is<T>() работает не только со скалярами: is<JsonObject>() и is<JsonArray>() проверяют, что под ключом лежит структура, прежде чем лезть внутрь с цепочкой или индексами. Для массивов я ставлю такую проверку всегда: сервер меняет длину и даже тип элементов без предупреждений, а цикл по несуществующему массиву выдаёт те же тихие нули. Мнение с условием: на первом поле пакета is<T>() у меня не стоит — проверка кода разбора уже гарантирует документ; стоит оно на полях с историей смены типа и на всём, что пришло от чужого устройства. Внутри своего протокола я знаю тип каждого поля наизусть — лишние проверки там только шум.

is<T>() и as<T>() движок симулятора не эмулирует — это честная граница раздела. Но сам сюжет guarding воспроизводится полностью: ключ есть, значение не того типа. В скетче ниже два пакета: с mode строкой и с mode числом. Роль проверки типа играет сравнение значения с ожидаемым: if (doc.mode == "auto") срабатывает только для строкового пакета. Содержание проверки то же, что у is<const char*>() на плате: «значение — та строка, которую я жду?». Запустите и посмотрите на второй пакет: containsKey отвечает 1, а сравнение проходит мимо — ключ на месте, тип чужой, и ветка с запасным поведением забирает управление себе.

Чтение значений в симуляторе идёт точечной формой doc.mode — на плате то же место занимает doc["mode"]: в тексте скетча это оговорено в комментарии, чтобы на живой плате вы не искали, почему точечная форма не компилируется. Ещё одна упрощённость: строка «не того типа» здесь ловится только сравнением с конкретным ожидаемым значением; на плате is<const char*>() пропустит и "night", и пустую строку — поэтому на плате за is следует проверка содержимого, если от строки зависит логика. Запасная проверка стоит строки — и закрывает вопрос «а что именно пришло» без всяких is.

Третье следствие видно в списке экспериментов: сравнение с ожидаемым значением строже, чем is<const char*>() на плате. Сравнение с "auto" отвергнет и "night", и "1" — на плате обе строки прошли бы is как строки. Это не упрощение, а другая семантика: сравнение проверяет значение, is проверяет тип. Выбирайте по смыслу: когда логика зависит от конкретного режима — сравнение; когда от класса значения — is. На плате я часто ставлю обе: сначала is, потом содержимое.

Раздел теперь закрывает весь цикл: собрать документ — serializeJson, прочитать — с запасными значениями и проверками, защититься от чужих типов. Дальше по плану раздела — фильтры разбора, которые экономят память на Uno, и JSON поверх UART. Применить guarding удобнее всего там, где встречаются два мира: возьмите HTTP-запрос с ESP32 — чужой сервер, чужие типы, ваш разбор с тремя ветками. Домашнее задание: добавьте guarding к разбору из урока про HTTP-ответ и добейтесь, чтобы вместо нуля на экране скетч печатал в журнале «тип не тот» — тогда следующий чужой апдейт вы заметите по логу, а не по молчащему прибору. И заведите правило расширенной проверки: любое поле, чей тип менялся хоть раз в жизни протокола, получает is<T>() навсегда — вторая смена типа случается быстрее первой. Мой итоговый чек-лист guarding: containsKey на отсутствие, isNull на пустоту, is<T>() на тип, as<T>() на чтение — четыре вопроса в этом порядке.