Why dont RealTime Embedded programmers use Exception Handling?

[NewToCPP]

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.

 

[Victor Bazarov]

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

 

[Phlip]

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.

 

[red floyd]

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)...

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

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.

 

[Ian Collins]

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.

 

[noone]

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.

 

[NewToCPP]

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.

 

[Ian Collins]

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.

 

[Frederick Gotham]

Ian Collins posted:

Don't listen to them, do your own tests with your own tools. Whenever I
have done this, exception code has been faster.

Exceptional.

 

[noone]

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.

 

[Peter]

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.

 

[dayton]

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

 

[Christopher Benson-Manica]

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.

 

[NewToCPP]

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.

 

[noone]

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.

 

[dayton]

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