Date
1 - 5 of 5
Extending Error Codes
|
laczenJMS
Hello Zephyr Developers,
I recently had a request to change the error codes in a zephyr module to use the standard supplied error codes. Doing so would reduce the descriptiveness of the error codes so I did not really like this. However in my module I was using error codes (-) 1 to 10, and I think this was a bad idea. If someone needs to check the error code he/she might end up looking at errno.h and finding a completely different definition. Would it not be a good idea to allow extending the standard error codes with module (subsystem) specific error codes that can be as descriptive as required by allowing modules to use error codes above a specific value. E.g. any module can use it's own error codes starting from 0x7F00 to 0x7FFF. This way it is possible to avoid overlap between standard errors and "user" errors. What's your opinion ? Kind regards, Jehudi |
|
|
|
Puzdrowski, Andrzej
I also see that error cods defined in <errno.h> are insufficient.
toggle quoted message
Show quoted text
I think definition value-space for module specific codes are good idea in general. But I'm afraid we can go down the road in case we relaxed the line. Also we can consider addition of generic codes to existing definitions (which is better idea). Andrzej -----Original Message-----
From: devel@... [mailto:devel@...] On Behalf Of laczenJMS Sent: Friday, April 27, 2018 5:32 PM To: devel@... Subject: [Zephyr-devel] Extending Error Codes Hello Zephyr Developers, I recently had a request to change the error codes in a zephyr module to use the standard supplied error codes. Doing so would reduce the descriptiveness of the error codes so I did not really like this. However in my module I was using error codes (-) 1 to 10, and I think this was a bad idea. If someone needs to check the error code he/she might end up looking at errno.h and finding a completely different definition. Would it not be a good idea to allow extending the standard error codes with module (subsystem) specific error codes that can be as descriptive as required by allowing modules to use error codes above a specific value. E.g. any module can use it's own error codes starting from 0x7F00 to 0x7FFF. This way it is possible to avoid overlap between standard errors and "user" errors. What's your opinion ? Kind regards, Jehudi |
|
|
|
piotr.ziecik@...
Hi.
toggle quoted message
Show quoted text
I do not think that per-module error codes are good idea. First, you cannot to this: foo_error_t foo(void) { boo_error_t error = boo(); if (error != BOO_SUCCESS) return error; // Here you are changing the meaning of the message. If the error will be propagated further the correct meaning will dissolve and the error code will become useless. } To solve the problem shown above you will need a translation: foo_error_t foo(void) { boo_error_t error = boo(); // Waste of space here: copy-paste to each function using BOO and hard to maintain: switch (error) { case BOO_SUCCESS: return FOO_SUCCESS; case BOO_NOT_FOUND: return FOO_NOT_FOUND; default: // Please maintain me 😊 __ASSERT(false); } } IMHO the best solution is to extend the errno.h, but please remember that all errors defined there must be generic (reusable across different modules). Best Regards, Piotr Zięcik Senior Firmware Engineer M: +48 698 726 973 Nordic Semiconductor Poland sp. z o.o. ul.Bratyslawska 1A, 31-201 Krakow, Poland www.nordicsemi.com -----Original Message-----
From: devel@... [mailto:devel@...] On Behalf Of Puzdrowski, Andrzej Sent: Monday, April 30, 2018 3:53 PM To: devel@... Subject: Re: [Zephyr-devel] Extending Error Codes I also see that error cods defined in <errno.h> are insufficient. I think definition value-space for module specific codes are good idea in general. But I'm afraid we can go down the road in case we relaxed the line. Also we can consider addition of generic codes to existing definitions (which is better idea). Andrzej -----Original Message----- From: devel@... [mailto:devel@...] On Behalf Of laczenJMS Sent: Friday, April 27, 2018 5:32 PM To: devel@... Subject: [Zephyr-devel] Extending Error Codes Hello Zephyr Developers, I recently had a request to change the error codes in a zephyr module to use the standard supplied error codes. Doing so would reduce the descriptiveness of the error codes so I did not really like this. However in my module I was using error codes (-) 1 to 10, and I think this was a bad idea. If someone needs to check the error code he/she might end up looking at errno.h and finding a completely different definition. Would it not be a good idea to allow extending the standard error codes with module (subsystem) specific error codes that can be as descriptive as required by allowing modules to use error codes above a specific value. E.g. any module can use it's own error codes starting from 0x7F00 to 0x7FFF. This way it is possible to avoid overlap between standard errors and "user" errors. What's your opinion ? Kind regards, Jehudi |
|
|
|
Carles Cufi
Hi Piotr,
toggle quoted message
Show quoted text
-----Original Message-----I agree. I think a single set of generic error codes that are flexible enough to convey the message are a better approach. That still leaves out how to extend errno.h for both newlib and minimal. Should we have an extended errno-zephyr.h for Zephyr somewhere in include/? Carles
|
|
|
|
Zięcik, Piotr <piotr.ziecik@...>
toggle quoted message
Show quoted text
-----Original Message-----
From: Cufi, Carles Sent: Monday, May 07, 2018 11:57 AM To: Zięcik, Piotr <Piotr.Ziecik@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; devel@... Subject: RE: [Zephyr-devel] Extending Error Codes Hi.Hi.I agree. I think a single set of generic error codes that are flexible enough to convey the message are a better approach. I have looked into the error list available in ./lib/libc/minimal/include/errno.h and it looks that there are plenty of errors defined, however most of these defines are rather high-level. If this is not enough, I could recommend following the Linux approach, which in my opinion is pretty simple and gives some flexibility: We can divide the error lists in 2 parts, listed in 2 different files. The first file, will cover generic, high level errors (and could be provided by libc). The second file will be zephyr-specific. There should be also single errno.h header, which will include both libc and zephyr headers. What do you think? Best Regards, Piotr Zięcik. |
|
|