Hi Bob,
> Hello everyone,
>
> This is my first commit on this mailing list, so Ill briefly introduce
> myself: I'm Bob Fels, software engineer in embedded real time systems.
> For that I mainly use C, but I am also experienced in C++, Java, Python,
> Perl, various assembly flavors etc.
>
> I am every interested in using a service approach in embedded software,
> so Celix drew my interest.
Good to see you here!
>
> switch (my_function())
> {
> case CELIX_RETURN_OK:
> break;
> case CELIX_RETURN_OUT_OF_MEMORY:
> /* Do someting */
> break;
> case CELIX_RETURN_DEVIDE_BY_ZERO:
> /* Do someting */
> break;
> default:
> /* This is bad, return value not expected */
> break;
> }
> Don't forget to keep Celix simple however ;).
> I agree with your idea to go for the easy solution. It will keep your
> code simple. As I showed, even without libex you can still make the code
> look very recognizable and if you really want to, with some defines you
> can make it look more TRY-CATCHY.
Good arguments, and I agree. I will start using the easy solution.
This raises an other question though, in the example you gave, there
is a dedicated CELIX_OUT_OF_MEM. Is it a good idea to redefine
existing errors from errno.h into "own" errors? Or should errors be
reused? Since I am looking at APR, I tried to see how they solved it,
an apparently they wrap existing number into their own:
>From https://svn.apache.org/repos/asf/apr/apr/trunk/include/apr_errno.h
#ifdef ENOMEM
#define APR_ENOMEM ENOMEM
#else
#define APR_ENOMEM (APR_OS_START_CANONERR + 7)
#endif
I think it makes more sense to have dedicated CELIX_ errors. This
keeps the api clean in the way that the only reported errors are
CELIX_ errors. Basically what APR also does.
>
> I hope this information/thoughts helps,
> best regards,
> Bob Fels
This definitely helps! Looking forward to more remarks and your
insight in embedded code/platforms!
--
Kind regards,
Alexander Broekhuis
