473,320 Members | 1,947 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Why dont RealTime Embedded programmers use Exception Handling?

I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?

Thanks.

Jul 17 '06 #1
16 6885
NewToCPP wrote:
I have seen at several places that C++ programmers writing for
RealTime Embedded applications dont use Exception Handling. They dont
like Throw/catch concept. WHY?
You should probably ask in the newsgroup about embedded applications.
Some people don't use templates in their programs, some don't use
multiple inheritance. From C++ point of view they are all language
features. C++ assigns no weight to its parts whatsoever.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jul 17 '06 #2
NewToCPP wrote:
I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?
It depends on the construct and the platform. Exception handling adds more
opcodes to a program - increasing its footprint.

And some embedded platforms don't have room for std::stringstream, so
programmers make due.

--
Phlip
Jul 17 '06 #3
NewToCPP wrote:
I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?

Thanks.
Also depends on the problem domain. Certain domains are extremely
conservative, and without a "killer rationale" to use them, would prefer
to retain the use of error codes. In addition, many embedded domains
don't have a lot of call-stack depth, so that "handle at the correct
level" means that there isn't a lot of "return the error code up the stack."

I've just fought this battle (and lost)...

Jul 17 '06 #4
NewToCPP wrote:
I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?
There are may possible reasons. They can use compiler that can generate code
more compact or faster if exception are disabled. They can consider that in
his type of system nothing can be considered exceptional. They can have
tools to verify time constraints that does not work well with exceptions.
They can want to make his code portable to platforms without a decent
standard complaint c++ compiler...

The better way to investigate the phenomenon will be to ask to the people
involved.

--
Salu2
Jul 17 '06 #5
NewToCPP wrote:
I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?
Some of us do. Some embedded compilers generate piss poor code with
exceptions enabled, so it you are stuck with one of those, you often
don't have a choice.

--
Ian Collins.
Jul 17 '06 #6
On Mon, 17 Jul 2006 13:08:14 -0700, NewToCPP wrote:
I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?

While the other answers have merit, I believe it is more an issue of
familiarity. I don't believe c++ is as mainstream for embedded
applications as c is...and it seems to me that embedded programmers who
are using c++ are traditional c programmers and have that c mindset, but
attempt to add c++ features to their code. There is also way much
misinformation about efficiency of features and how they are implemented.
that tends to scare folks since it introduces more uncertainty.

I use c++ (full features with STL) in embedded design but I've got some
pretty beefy boards so cpu cycles and memory footprint aren't as much of a
concern to me as using tools that effectively model the task at a higher
level.

regarding exceptions specificially...I think they are an overrated
language feature and that is one thing that pisses me off about java: that
you have to use them in cases where you might not want to.
Jul 22 '06 #7
noone,

Several people are saying that performance will go down if I use
exceptions.. and several embedded programmers are saying that it
increases number of instructions if I use exceptions...

You are saying that it is a overrated feature.. are you saying that
that the advantages of using exceptions in C++ are less than the
disadvantages of using them?

thanks.

Jul 24 '06 #8
NewToCPP wrote:
noone,

Several people are saying that performance will go down if I use
exceptions.. and several embedded programmers are saying that it
increases number of instructions if I use exceptions...
Don't listen to them, do your own tests with your own tools. Whenever I
have done this, exception code has been faster.

--
Ian Collins.
Jul 24 '06 #9
Ian Collins posted:
>Several people are saying that performance will go down if I use
exceptions.. and several embedded programmers are saying that it
increases number of instructions if I use exceptions...
Don't listen to them, do your own tests with your own tools. Whenever I
have done this, exception code has been faster.

Exceptional.

--

Frederick Gotham
Jul 24 '06 #10
On Sun, 23 Jul 2006 19:38:34 -0700, NewToCPP wrote:
noone,

Several people are saying that performance will go down if I use
exceptions.. and several embedded programmers are saying that it
increases number of instructions if I use exceptions...
As was pointed out by another, test it out...If it works for you then
great.

You are saying that it is a overrated feature.. are you saying that that
the advantages of using exceptions in C++ are less than the
disadvantages of using them?
I probably fall into that category of ole-time C programmer so I'm more
comfortable with checking function value returns and status variables.

Jul 25 '06 #11

NewToCPP wrote:
I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?

Thanks.
some people have a problem with C++ Exception Handling.
Don't ask me why
-- I see C++ Exception Handling as even more important than templates.
I guess they only know that they cannot go on programming like they
used to and they don't want to relearn Exception-safe programming.

Jul 25 '06 #12
NewToCPP wrote:
I have seen at several places that C++ programmers writing for RealTime
Embedded applications dont use Exception Handling. They dont like
Throw/catch concept. WHY?
My shop doesn't use exceptions for the following possibly
invalid reasons:

0) Earlier compilers did a poor job of generating code.
1) Earlier developers over-used exceptions. The used
exceptions to return status rather than just exceptional conditions.
2) Earlier developers were not aware of how to write
exception-safe code. They didn't follow the law-of-threes and
didn't make the assignment operator exception-safe.
3) Most of the developers write C in C++ (at least we got them
to stop writing FORTRAN in C++).
3) Unexpected exception handling in C++ is incompatible with
most embedded systems (actually IMHO it is incompatible with
most applications).

If you know how to write exception-safe code, you get big
rewards. You can't use the RAII paradigm without using
exceptions for the simple reason exceptions are the only way to
report an error from a constructor. Use constructors to
encapsulate any change of state if you need to clean up that
change of state later. Unless you use RAII you're likely to
have memory leaks, unreleased locks, and other resource leaks.
Make the compiler do the work for you.
Glen Dayton
Jul 26 '06 #13
noone <no***@all.comwrote:
regarding exceptions specificially...I think they are an overrated
language feature and that is one thing that pisses me off about java: that
you have to use them in cases where you might not want to.
Exceptions can be used, misused, or abused like many other language
features. It's fair to note that Java's pedantry regarding exceptions
is not always helpful; however, a well-designed exception framework
can be indispensible.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Jul 26 '06 #14
dayton,

Very good list of reasons explaining why some programmers dont use
Exceptions.

The last point of yours says "Unexpected exception handling in C++ is
incompatible with most embedded systems (actually IMHO it is
incompatible with most applications)."

What do you mean by "Unexpected exception handling in C++"?

Thanks.

Jul 26 '06 #15
You can't use the RAII paradigm without using
exceptions for the simple reason exceptions are the only way to
report an error from a constructor.
Good point, and really the only reason I consider valid for using
exceptions...but we've already covered my bias against them.
Jul 28 '06 #16
What do you mean by "Unexpected exception handling in C++"?
If you use exception signatures on your functions, and if
exception gets thrown that doesn't match one of the exceptions
in the signature, the default behavior is to terminate the
application.

If you fail to catch an exception, the default behavior is to
terminate the application. Because C++ allows you to throw
anything, you'll have to use a catch (...) block at the top-most
level of your module, but then you'll lose all information
contained in the exception, and you may not have control over
the code that calls your code. If you're writing a library,
terminating the customer's application is a really hostile thing
to do.

Glen Dayton
Jul 28 '06 #17

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Master of C++ | last post by:
Hi, I am an absolute newbie to Exception Handling, and I am trying to retrofit exception handling to a LOT of C++ code that I've written earlier. I am just looking for a bare-bones, low-tech...
2
by: JohnR | last post by:
Hi all. In my program I try to handle all obvious potential errors with structured error handling (try-catch) block. What I would like to do is have an 'overall' error handler that would...
49
by: Alex Vinokur | last post by:
Are there any restrictions/problems for use of C++ STL in development in embedded systems? In particular: * Does STL require too much space/memory? * Is 'implementation of STL...
10
by: Alex Vinokur | last post by:
The memory allocation issue in embedded systems is usually critical.. How can one manage that? 1. Via 'new' char* p = new (nothrow) char ; if (p == 0) { // He we know that it is impossible...
16
by: lawrence k | last post by:
I've made it habit to check all returns in my code, and usually, on most projects, I'll have an error function that reports error messages to some central location. I recently worked on a project...
1
by: CptDondo | last post by:
OK, let me explain what I am trying to do. I have an embedded PC that runs a httpd+php server and controls a machine. I have a browser front end that provides the HMI (human machine interface)...
41
by: Baron Samedi | last post by:
I want to produce a piece of software for embedded systems, generally telecoms based, mostly running on ARM processors, but I can't guarantee that, of course. My software should work along with...
30
by: =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= | last post by:
Let's say we had a simple function for returning the amount of days in a month: unsigned DaysInMonth(unsigned const month) { switch (month) { case 8: case 3: case 5:
0
by: Marcin Krol | last post by:
Right, I didn't realize before that Python interpreter has its own signal handling routines. Now I am able to handle signals in Python code, but it still barfs on exit: import time import...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.