By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,905 Members | 1,616 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,905 IT Pros & Developers. It's quick & easy.

Why dont RealTime Embedded programmers use Exception Handling?

P: n/a
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
Share this Question
Share on Google+
16 Replies


P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a

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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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 discussion thread is closed

Replies have been disabled for this discussion.