g++ on Cortex-M with no dynamic memory

To my knowledge exception handling requires something like RTTI, but not necessarily a heap (AFAIK current implemnentations do).

I've had a few discussions about exceptions. The current aim of the anti-exception advocates (as heared in SG14) is that exceptions are too costly in time. This is mostly from gaming, fast trading and google.

My (main) problem with exceptions is the use of the heap.

Wouter "Objects? No thanks!" van Ooijen

I believe that exception handling does not need RTTI, unless you are using polymorphic exceptions (i.e., throwing specific exceptions and catching generic ones).

I am not keen on exceptions in embedded code, but the time costs are not the main issue. The run-time costs for code that could throw, but does not, are very small - often smaller than alternative explicit error handling code. I think the possibility of exceptions occurring may hinder optimisations - in particular, it could limit certain types of code re-ordering. There is also the cost in code space for all the stack unwind stuff.

I dislike exceptions simply because they are undocumented gotos. I don't like the idea of functions that can quietly fail in some way and hope that something further up the system can deal with it in a sensible manner. It can be okay on a PC desktop program to say that a particular operation failed, and carry on with rest of the tasks - if one web page fails to open correctly, the rest of the browser is still usable. But on embedded systems, /everything/ should work correctly all the time - if a bit of software is not necessary, it should not be part of the program. (Note that some things, such as hardware, may fail - but the software should correctly deal with those problems.)

Exceptions do not /have/ to use the heap. I had a quick google for this, and found that the gcc C++ library will try to get heap memory for an exception - but if it fails, it will use memory from a statically allocated "emergency buffer". It should not be too hard to make stubs for these functions for your own use, making exception handling always use a static buffer. The code will be implementation-specific, of course, and might be tightly tied to particular versions of the compiler.

Maybe, but the current implementations do.

That sound weird. If it can use the static buffer, why not use that anyway? Are you sure it isn't the other way round (a small-expection optimization similar to small-string optimization)?

Wouter "Objects? No thanks!" van Ooijen

I haven't looked at this in detail, nor have I tried to find documentation about /why/ it has this sort of implementation. So I can only speculate. And just to be clear, I am talking about PC or "big embedded system" implementations here, not memory-constrained devices.

Using an emergency buffer for exceptions will be limited. It puts a tight limit on the size of the object thrown (since it is statically allocated, and a bigger buffer is a waste of space), and it can only be used for one exception (unless you want to re-invent malloc). In a multi-threaded program, only one thread can use the emergency buffer at a time - there is a lock to protect it.

I don't think it would be a bad idea to have a small buffer per thread that would be used for common exception types as a first choice, then fall back to heap for big exceptions, then to the emergency buffer if that fails too. But the current libstdc++ does not have such an implementation.

Here's a nice write-up on how libstdc++ manages exceptions, and how to write a replacement:

Thanks. I haven't read it yet, so I can't comment on it - but I will do so as soon as I get the chance.

thanks, really interesting article.

Bye Jack