3 ms·

Depends on the what the embedded system is doing. Right now I am working on a system with a real-time cycle handler and a non-real time thread that handles RPC

Depends on the what the embedded system is doing. Right now I am working on a system with a real-time cycle handler and a non-real time thread that handles RPCs. For the real-time part, what you say is more-or less right. But in the RPC thread is a lot more like non-embedded code: if I detect an error deep in the stack, I can just throw an exception and catch at the top level. The PC gets an error message and the embedded system treats it as a no-op.

TickleSteve 10y ago
defined recovery cases are not exceptions. thats program logic. Placing program logic into exception handlers is obfuscation.
- adrianratnapala 10y ago
  Can you unpack this for me? Are you talking about the RPC error handling I described? As best I understand your argument, it is circular. You assert that if it is an exception, then the only thing to do is reset. When I give a counter-example, you define it as "not an exception" -- presumably because a reset is not desirable. I agree that defined recovery cases are part of the program logic. But what reason -- beyond a slogan, do you have for reject exceptions as a tool for implmenting that part of the logic? How is it "obfuscation" to do the catch-and-report in the RPC front-end? The danger I know of with exceptions is that throw sites are invisible, which makes it easy to neglect clean-up actions on error paths. Is that what you meant?
  - TickleSteve 10y ago
    all I'm saying is that if you have a defined recovery process, put it in normal logic, not exception handlers. If you don't have a defined recovery process, that technically would be an exceptional case... but because of the nature of embedded systems, a reset is the only reasonable recovery mechanism (a catch all). Therefore, there is no place for exception handling in embedded systems (as a general rule. Of course there are exceptions... ;o) The dislike of exception handlers is also that they harm readability, The further you get away from a call-site the more context you have to hold in your head making it more complex. Keeping error recovery local to the logic improves everything, from readability to code size to complexity and performance.

TickleSteve 10y ago

defined recovery cases are not exceptions. thats program logic. Placing program logic into exception handlers is obfuscation.

adrianratnapala 10y ago
Can you unpack this for me? Are you talking about the RPC error handling I described? As best I understand your argument, it is circular. You assert that if it is an exception, then the only thing to do is reset. When I give a counter-example, you define it as "not an exception" -- presumably because a reset is not desirable. I agree that defined recovery cases are part of the program logic. But what reason -- beyond a slogan, do you have for reject exceptions as a tool for implmenting that part of the logic? How is it "obfuscation" to do the catch-and-report in the RPC front-end? The danger I know of with exceptions is that throw sites are invisible, which makes it easy to neglect clean-up actions on error paths. Is that what you meant?
- TickleSteve 10y ago
  all I'm saying is that if you have a defined recovery process, put it in normal logic, not exception handlers. If you don't have a defined recovery process, that technically would be an exceptional case... but because of the nature of embedded systems, a reset is the only reasonable recovery mechanism (a catch all). Therefore, there is no place for exception handling in embedded systems (as a general rule. Of course there are exceptions... ;o) The dislike of exception handlers is also that they harm readability, The further you get away from a call-site the more context you have to hold in your head making it more complex. Keeping error recovery local to the logic improves everything, from readability to code size to complexity and performance.