Electronics > Microcontrollers

C++ Exception handlers

(1/7) > >>

ee851:
I am an experienced C programmer.    I have dabbled with assembler programming, but nothing major.    One impetus for me to learn C++ programming is its ability to throw and catch exceptions.     However, would this be useful for programming of embedded systems, I wonder ?      If you have used this tool in embedded programming, please share your experiences.

One of the first things I have been wondering is this:   Is exception handling (A) a software design technique to identify and to handle foreseen exceptions without bringing down the whole system, or (B) a debugging technique to identify and isolate some unforeseen set of events that led to the failure of a system, or (C) something else.

If you have experienced another situation where exception-handling helped solve a problem, please share.

McMonster:
It's certainly the A option, safely handling forseeable events like trying to open a file that does not exist. But (assuming PC programming in this case) it's also handy for debugging, if your application fails on a kind of event that wasn't forseen they produce a stack trace and and something ranging from a generic kind of error to a detailed message regarding the event (depends on how well your code uses them) with pointing you to exact location (file and number of the line) in your code. This can lead to identifying a bug or another event you should anticipate and handle. There's also a kind of exception called an error, the difference is that they do identify a fatal condition in your application that you can't anticipate and usually can't recover from.

However electronics and microcontrollers are just my hobby, so I can't tell you anything detailed about how they're used in embedded systems. I've heard that they're not used on small micros because they use a lot of memory.

nctnico:
I program a lot in C++ but I don't like exception handlers very much. Its like using if (error) goto handler; They are especially irritating if they occur in libraries. I prefer functions which return an error value and work from there.

As with using C++ on embedded systems I'm sure it will have its benefits. Deep down below a C++ object is a struct with data members and function pointers. If you declare a new instance the functions pointers get filled and the so called constructor is called in order to initialize the data members. Unless you are going to use late binding I doubt you'll have much overhead unlike many people think. Actually, in many cases I see people emulate C++ behaviour. The Linux kernel is a very good example. If you want C++ features why not use C++ right away?

But... with ever increasing complexity of projects C of C++ are getting in the way of programming. Certainly C++ has a much better string type and the STL libraries make using pointers and dynamic allocation of memory unnecessary but still I think there is room for improvement. I'd like to give eLua a try one day (see http://www.eluaproject.net/ ). Lua is a 4th generation programming language which takes a lot of the uninteresting low level stuff away.

amspire:
I believe exceptions are not supported for C++ programming using the g++ compiler with the Atmel AVR family. In the limited amount of embedded programming I have done, it is not something I like to do. Exceptions allow you to back out of many levels of function calls quickly, but I like avoiding too many levels of function calls anyway. Function calls can chew up the very limited RAM in embedded processors, and also  chew up time, so I have often limited myself to no more then 4 levels of function calls maximum.  I tend to more of a flat level State approach to programming and instead of throwing an exception, I just change to a different State.

So say I have a watch dog timer for a communications process. If the watch dog timer trips indicating that the handshake has totally stalled, instead of throwing an exception, I would just change a State byte so that next time the main loop checks for the current state, it will go to a State that resets the communications. In embedded programs, I try and write all loops so the code can never get stuck in a loop. I make sure that every State function will run very quickly, even if that means to complete a task, the State function has to be run many times.

There are probably better approaches, but this method works for me.

Richard.

IanB:
As to the mechanics of exceptions in C++, they are essentially a return statement executed somewhere in the middle of a routine and returning a value of some type that you can examine later. When the exception is thrown the current level of the call stack is tidily unwound just as if a return had been executed, and control passes to the next routine up the stack. If this level does not catch and handle the exception then the exception is thrown again and the process of unwinding the call stack is repeated. It continues all the way up the call stack until main() is reached, and if that does not handle the exception it exits and returns control to the operating system. Of course in an embedded system there is no OS and it is probably a bad idea to exit from main. So exceptions are most likely not a good plan in this environment.

The benefit of exceptions is that they allow you to place cause and effect in specific places where they make most sense, to avoid the need for checking the return status of every function you call, and to provide an error return path from code in object-oriented systems that doesn't have a normal return path with a status code. Essentially the main purpose of exceptions is to provide for an alternate flow of control through the code in a tidy and organized manner, so that you have a "normal path" and an "exception path". However, exceptions can be abused, they can slow your code down if misused, and they can lead to memory leaks or inconsistent states. Exceptions have a place in high level application programming, but not in low level systems programming. It is notable that C was designed as a low level systems programming language and C does not have exceptions.

Navigation

[0] Message Index

[#] Next page