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.
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@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of laczenJMS
Sent: Friday, April 27, 2018 5:32 PM
To: devel@lists.zephyrproject.org
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.

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@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of Puzdrowski, Andrzej
Sent: Monday, April 30, 2018 3:53 PM
To: devel@lists.zephyrproject.org
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@lists.zephyrproject.org [mailto:devel@lists.zephyrproject.org] On Behalf Of laczenJMS
Sent: Friday, April 27, 2018 5:32 PM
To: devel@lists.zephyrproject.org
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,

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Ziecik, Piotr
Sent: 30 April 2018 16:20
To: Puzdrowski, Andrzej <Andrzej.Puzdrowski@nordicsemi.no>;
devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Extending Error Codes

Hi.

I do not think that per-module error codes are good idea.
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



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@lists.zephyrproject.org
[mailto:devel@lists.zephyrproject.org] On Behalf Of Puzdrowski, Andrzej
Sent: Monday, April 30, 2018 3:53 PM
To: devel@lists.zephyrproject.org
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@lists.zephyrproject.org
[mailto:devel@lists.zephyrproject.org] On Behalf Of laczenJMS
Sent: Friday, April 27, 2018 5:32 PM
To: devel@lists.zephyrproject.org
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








Zięcik, Piotr <piotr.ziecik@...>
 

-----Original Message-----
From: Cufi, Carles
Sent: Monday, May 07, 2018 11:57 AM
To: Zięcik, Piotr <Piotr.Ziecik@nordicsemi.no>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@nordicsemi.no>; devel@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] Extending Error Codes

Hi.

I do not think that per-module error codes are good idea.
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/?
Hi.

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.