ESP32 define custom esp_err_t errors and best practice

fiveowle5
Posts: 2
Joined: Tue Dec 03, 2019 4:16 pm

ESP32 define custom esp_err_t errors and best practice

Postby fiveowle5 » Thu Jan 09, 2020 1:10 pm

Hello all,

Is it possible to define custom esp_err_t types in addition to the existing esp errors?

I can see the definition of the esp error codes in some header files. It defines an error base + the unique error number as hex.
For instance in esp_ota_ops.h:

Code: Select all

#define ESP_ERR_OTA_BASE                         0x1500                     /*!< Base error code for ota_ops api */
#define ESP_ERR_OTA_PARTITION_CONFLICT           (ESP_ERR_OTA_BASE + 0x01)  /*!< Error if request was to write or erase the current running partition */
Is it possible to add my custom errors in my components header files in addition with the existing ones? If yes how to ensure that the error base does not exist and will not be in conflict by incoming ESP-IDF Updates?

If adding custom esp_err_t types is not possible what is the best practice to return ESP error codes and my own defined error codes from my functions?

Thanks

ESP_Angus
Posts: 2073
Joined: Sun May 08, 2016 4:11 am

Re: ESP32 define custom esp_err_t errors and best practice

Postby ESP_Angus » Fri Jan 10, 2020 4:37 am

Hi fiveowle,

I'm afraid we don't have a good solution for this yet. We have discussed adding a "user" reserved range where, but other people also publish IDF components to be shared and it's not helpful if someone publishes a thirdparty component that also uses codes in the "user" range.

We are looking into a better solution to apply in the future.

For now, my recommendation would be:
  • If you can use only the existing built-in esp_err_t error values, return esp_err_t. BTW, if there is some reasonably generic error that you think we've missed out, feel free to make a feature request to add it.
  • If your API needs more specific errors, create a totally new enum type for its result values.
Angus

boarchuz
Posts: 206
Joined: Tue Aug 21, 2018 5:28 am

Re: ESP32 define custom esp_err_t errors and best practice

Postby boarchuz » Fri Jan 10, 2020 7:22 am

I had the exact same query as fiveowle5.
ESP_Angus wrote:
Fri Jan 10, 2020 4:37 am
If you can use only the existing built-in esp_err_t error values, return esp_err_t. BTW, if there is some reasonably generic error that you think we've missed out, feel free to make a feature request to add it.
https://docs.espressif.com/projects/esp ... codes.html
It seems there aren't all that many pre-defined, and a lot of potentially useful ones have component-specific prefixes which would make them awkward to use.

Would you be open to adding a whole bunch of them or is there a preference for keeping a limited number of vague ones?

Some that spring to mind just now:
  • NOT_CONFIGURED
  • NOT_INITIALIZED
  • NOT_READY
  • NOT_STARTED
  • NOT_STOPPED
  • BUSY / ACTIVE / IN_PROGRESS
  • IDLE
  • END / CANCEL / ABORT
  • COMPLETED
  • IGNORE
  • REPEAT / RETRY / AGAIN
  • WAIT
  • PENDING
  • RESET
  • DISCONNECTED
  • NOT_RESPONDING / NO_RESPONSE
  • READ_ONLY / PROTECTED
  • NOT_ALLOWED / DENIED / FORBIDDEN / NOT_AUTHORIZED
  • NOT_REGISTERED
  • DISABLED
  • EXPIRED
  • REMOVED
  • NOT_IMPLEMENTED
  • NOT_FOUND
  • NULL
  • MISMATCH
  • DUPLICATE / EXISTS
  • UNDEFINED
  • OUT_OF_RANGE
  • CONFLICT
  • FULL
  • EMPTY
  • INSUFFICIENT
  • EXCEEDED
  • STATE
  • MODE
  • METHOD
  • SIZE
  • LENGTH
  • NAME
  • KEY
  • VALUE
  • ENCODING
  • FORMAT
  • PROTOCOL
  • UNRECOGNIZED / UNKNOWN

fiveowle5
Posts: 2
Joined: Tue Dec 03, 2019 4:16 pm

Re: ESP32 define custom esp_err_t errors and best practice

Postby fiveowle5 » Tue Jan 14, 2020 9:12 am

Thanks for your responses. In that case I will implement my own enums.

Who is online

Users browsing this forum: Baidu [Spider], Bing [Bot] and 41 guests