celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.A. Fels" <troep...@gmail.com>
Subject Re: Exception Handling in C
Date Sun, 13 Feb 2011 18:01:24 GMT
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.

* Using returns

For exception handling the most easy way is using states as return
values of functions. This will keep your code really simple and you can
still have predictable returns (and can still comply with Misra rule
about one return per function).

The try-catch macros look nice indeed and looks like a good way to let
it like like the Java manner of exception handling, but I think
something like the following is very readable:

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 ;).

* setjmp/longjmp

Using setjmp and longjmp is possible even for real time systems as
exceptions should not be part of the normal flow of the application and
thus in exceptional situations the main thing that matters is getting
back to a stable state.

With setjmp and longjmp will make more return points in functions, so
code flow will be harder to determine, as you can jump up multiple
functions. Also you need to drag along that structure which has saved
your stack, so it will be in every function call.

Its no problem at all for threads in principle as you just save the
stack and instruction pointer. Don't use it between threads however, but
that will not happen with try-catch either. The other danger is that
because of the sudden "return" its very easy for example to forget to
release locks.

Advantage is that it indeed does exactly the same as a throw in Java.

* Conclusion

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.

I hope this information/thoughts helps,
best regards,
Bob Fels


On Sun, 2011-02-13 at 13:36 +0100, Alexander Broekhuis wrote:
> Hello everyone,
> 
> Now that everything is in SVN, I would like to start working on the code again.
> 
> There is one important aspect which still needs a solution: Exception handling
> Celix follows the OSGi spec (Java), but since C doesn't have
> exceptions like Java, a solution is needed to be able to report
> errors/exceptions.
> 
> I've been looking on the web, and found 2 possible solutions.
> 
> 1) Using a library that uses setjmp/longjmp:
> Examples are:
> - http://libexcept.sourceforge.net/
> - http://www.nicemice.net/cexcept/
> - http://code.google.com/p/exceptions4c/
> 
> 2) Use the return value of functions:
> - For example by simply returning a int value indicating the error
> - Use a library which supplies try/catch macros: http://code.google.com/p/libex/
> 
> The first solution makes it possible to have an API very similar to
> the OSGi spec, but I am not sure how setjmp and longjmp interact with
> threads and real time behavior.
> The second solution is the most simple, and with the help of a library
> it is still possible to have clear code with try/catch constructs.
> 
> Does anyone have any experience with these kind of libraries?
> 
> For now I tend to lean towards using a simple solution, either simply
> returning the error code, or using something like libex (which is
> lgpl, which might be a problem..).
> 



Mime
View raw message