Disclaimer. Я не профессиональный программист. Ну, когда-то приходилось кодить на asm-e, C/C++. Работал в 1С-франчайзинговой конторе, реально кодил в 1С. Но это времена далекой молодости. Сейчас, программирую от случая к случаю, для себя и в образовательных целях. Уровень — ну так, несложные олимпиадные задачи. Поэтому, в качестве программиста я являюсь любителем.
Итак, после того, как я научился раскрашивать on-board RGB-светодиод на ESP32-S3, пришло время более серьезных задач. Сразу скажу, что я решил использовать нативный ESP-IDF в связке с Espressif-IDE. Ну, я так решил, что родной SDK будет роднее и ближе.
В свое время, на Arduino мне сильно не хватало WiFi и прочих коммуникаций, поэтому, первое, за что я решил схватиться — это WiFi. Ну, сказано — сделано, полез в доки.
Где-то в недрах прочитал мысль, вкратце, по-русски, анализируйте ошибки как можно чаще. Ну что-ж, совет не лишен смысла, я сам придерживаюсь такого же мнения. Поэтому, первым делом, полез в раздел Error handling…
Раздел 4.12 Error Handling сообщает нам, что существует 2 типа ошибок: восстановимые (recoverable) и невосстановимые (unrecoverable). Ну, хорошо, согласен. Дальше идут примеры ошибок обоих типов. Так, к восстановимым ошибкам относятся ошибки, возвращаемые в виде кодов ошибок функциями или полученные в результате перехвата исключений в C++. А невосстановимые ошибки — это ошибки системного уровня, ошибки неправильных инструкций ЦП (с чем я согласен) и ошибки, вызванные ассертами или аналогичными методами! Стоп! То есть, к невосстановимым ошибкам относятся те, которые изначально запрограммированные, как невосстановимые, без учета их тяжести! И это уже начало напрягать, и как выяснилось, не зря!
Второе, что меня напрягло — это обилие макросов ESP_ERROR_CHECK() в примерах. Полез в доки посмореть, что за зверь:
ESP_ERROR_CHECK macro serves similar purpose as assert, except that it checks esp_err_t value rather
than a bool condition. If the argument of ESP_ERROR_CHECK is not equal ESP_OK, then an error message is
printed on the console, and abort() is called.
Стоп-стоп-стоп…. Что значит «бух в котел и там сварился…»? В том плане, что если аргумент не ESP_OK, то печатается сообщение об ошибке и затем вызывается abort()? А с какой целью, извините?
Постараюсь проиллюстрировать примером из туториала по WiFi:
void wifi_init_sta(void) { s_wifi_event_group = xEventGroupCreate(); ESP_ERROR_CHECK(esp_netif_init());
То есть, если по какой-то причине, не удалось инициализировать WiFi, то все приложение останавливается? Так?
Хорошо, придирчивый читатель скажет, что никто не заставляет использовать макрос ESP_ERROR_CHECK(), Во-вторых, есть макрос ESP_ERROR_CHECK_WITHOUT_ABORT().
Отлично, но давайте почитаем описание функции esp_netif_create_default_wifi_sta():
Creates default WIFI STA. In case of any init error this API aborts.
Note: The API creates esp_netif object with default WiFi station config, attaches the netif to wifi and registers
wifi handlers to the default event loop. This API uses assert() to check for potential errors, so it could abort
the program. (Note that the default event loop needs to be created prior to calling this API)
Прекрасно! Просто великолепно! Если что-то пошло не так с инициализацией WiFi — гробим все приложение! То есть, вполне себе управляемую ситуацию неполадок с WiFi мы переводим в разряд невосстановимых ошибок просто используя assert()? Не потому, что это какая-то критическая ошибка, а потому, что мы так написали?
Эх, чувствую я, это только начало. Как бы не пришлось всю библиотеку перелопачивать, потому что так писать нельзя…