I realize this may be subjective, so will ask a concrete question, but first, background:
I have always been an embedded software engineer, but usually at Layer 3 or 2 of the OSI stack. I am not really a hardware guy. I have generally always done telecoms products, usually hand/cell-phones, which generally means something like an ARM 7 processor.
Now I find myself in a more generic embedded world, in a small start-up, where I might move to “not so powerful” processors (there’s the subjective bit) – I cannot predict which.
I have read quite a bit about debate about exception handling in C++ in embedded systems and there is no clear cut answer. There are some small worries about portability and a few about run-time, but it mostly seems to come down to code size (or am i reading the wrong debates?).
Now I have to make the decision whether to use or forego exception handling – for the whole company, for ever (it’s going into some very core s/w).
That may sound like “how long is a piece of string”, but someone might reply “if your piece of string is an 8051, then don’t. If, OTOH, it is …”.
Which way do I jump? Super-safe & lose a good feature, or exceptional code and maybe run into problems later?
In terms of performance, my understanding is that exceptions actually reduce the size and increase the performance of the normal execution paths of code, but make the exceptional/error paths more expensive. (often a lot more expensive).
So if your only concern is performance, I would say don’t worry about later. If today’s CPU can handle it, then tomorrows will as well.
However. In my opinion, exceptions are one of those features that require programmers to be smarter all of the time than programmers can be reasonably be expected to be. So I say – if you can stay away from exception based code. Stay away.
Have a look at Raymond Chen’s Cleaner, more elegant, and harder to recognize. He says it better than I could.