Sign In
Forgot Password?
Sign In | | Create Account

Exception handling in C++ - developers are wary

Colin Walls

Colin Walls

Posted May 12, 2014
2 Comments

As I mentioned last week, I am very much in “C++ mode” just now, mainly because I am preparing for some online classes. As a result of various social media contacts, I am getting some interesting impressions of how C++ is viewed among embedded developers. There is certainly much controversy. Some developers love it, but many are very critical.

Various aspects of the language concern engineers, and a particular one is exception handling …

The Exception Handling System [EHS] in C++ has nothing to be with exceptions in the sense of being hardware interrupts. It is designed to handle exceptional situations that are detected by the software. The intention is to provide a controlled failure mode, where a smooth exit from some deeply nested function calls is required [without resorting to goto].

EHSThe use of EHS is quite straightforward. Code that needs EHS activated during its execution is enclosed in a try block. A throw statement is used to assert an exception, which is identified by means of a class. Processing of the exception is performed by some code in a catch block. There is normally one catch block for each type of exception that may be asserted.

This seems quite neat and simple and does provide a way to write fairly readable code in which exception handling is needed. However, there are some key points that should make embedded developers wary:

  • If you are going to use the EHS, the additional code much be incorporated [a compiler option] for the entire application. It is not obvious to the human reader [or the compiler] what functions might be called [indirectly] by the code in a try block. This additional code adds size and reduces execution performance.
  • Many compilers default to including EHS code. This means that the unwitting user incorporates the overhead automatically, even if they have no intention of using the EHS. A compiler switch is normally available to activate or deactivate the EHS code generation.
  • If you application’s exception handling needs are simple, there are two ways to deploy the EHS which reduce the overheads:
    1. Use a generic catch block [where the type is specified with “…”] instead of one for each type of exception.
    2. Do not include any catch blocks. This results in the library function terminate() being called when an exception is thrown. This function can be customized.

Personally, I would shy away from using EHS, but, used with care, it may be beneficial to many designs. The overhead should be carefully measured.

EHS, exception handling

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 2

Post a Comment
Using macros (remember those?) you can invent "alternative keywords" (e.g. TRY, CATCH THROW) which will allow code to be compiled with or without exception handling enabled. The macro keyword substitutes do their obvious things with EH enabled. if EH is disabled, you can, with a configuration macro, cause TRY to become null, CATCH to become "if (false)" and THROW to cause some kind of assertion error. I, too, tend to shy away from EH in the real-time and smallish embedded projects in which I am typically involved. However, even for these, using the above macros allows EH to be turned on for testing and this can be very useful.An important part of testing is to test the error paths. An assertion error will kill your test suite but an exception can be caught and checked by the relevant test, allowing further tests to run normally.

Peter Bushell
8:14 AM May 14, 2014

Interesting ideas. Thanks Peter.

Colin Walls
7:42 AM May 15, 2014

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat