Re: How do you exception in your daily C++ programming?
On 8??28??, ????9??18??, Thomas Richter <t...@math.tu-berlin.de> wrote:
bingfeng wrote:
We are all konw traditional "return-value" or global errno varibale
management policy is error prone, but I have not seen using exception
thoroughly in an industrial applicaion. Most of my time is playing on
windows and I always found use exception which wraps GetLastError()
call automatically makes sense to me. It significent simplify the
program logics. However, I met following issues:
1. I log the error to file. what we can get from std::exception (I
derived my windows exception classes from it) is just an error
message. that's not enough since I don't know where the exception
throw! In order to make it available, I use a MACRO to collects the
file name and line number. I hate macro indeed, but do I have anothr
way?
You don't need exceptions to log errors. Just log them directly.
Instead, you should catch the exception where you can really do
something about the exceptional state. Failing that, try to handle it
gracefully and log the problem.
2. just do global catch in program entry (the main() function) is
clearly not enough.
It's not a solution since main() rarely can do anything about the
exceptional condition in first place.
I use multithread always and I provide global
catch for every thread entry so that an exception will not affect
other running threads. Any ideas for that?
Since C++ does (not yet) provide threads, one has to do that by hand. In
my approach, worker threads get messages indicating the jobs they have
to do, and exceptions thrown a side-thread which cannot be handled
thread-locally are captured in the main loop of the thread, which then
inserts the exception into the message, returning it to the main
(supervisor) thread. As soon as the exceptional return is received,
exception handling is continued in the main thread. Unfortunately, this
must be done manually.
3. we have some teams do different components respectively. Maybe
others do not like exception, maybe others do not use catch at all. In
order to avoid program termination from unhandled exception. I had to
catch(...) for each public interface and return an error code if
necessary. Any good practice here?
Shrug. For me it always depends on the project whether I may or may not
use exceptions. Exceptions are part of the interface of the software
developed, so the question is similar to "how to design a common
interface". It depends on the team. When interfacing to C, I'm providing
a boolean return of all functions, indicating an exception and a second
method returning the exception itself. Result codes except success
indicators are passed in the typical C sense, by a pointer to the
variable to be set.
AFAIK, using exception is not welcomed in some teams. I raise this
question since I want to collect good practices and argue that we can
use exception without exception. Indeed, I found some apps claim that
they need not use exception do few error management.
Whether exceptions are welcome also depends on the technology you have
available. For example, in one project I run we cannot support
exceptions since they require run-time support of the operating system
on at least one platform; but due to the architecture of the project,
such services are not available.
However, one thing for sure, using exceptions in a program requires a
pretty different programming style, very different from what a
programmer trained to C would be used to.
So long,
Thomas
er, actually using exception requires you rethink some common senses,
for example, when I found such code in C++ source, I don't know how to
refractor it indeed:
[code]
foo* f = new foo;
if (!f)
{
// log error here
return false
}
[/code]
the checking here is definitely useless. I have two options here:
1. add nothrow for the new operator
2. remove the checking
First option is unavailable since you need change lots of legacy
codes! For the second, that means we have a suit of complete exception
handling mechanism available and the fact is not.We cannot disable
this feature simple since some new codes and the STL use it. Exception
also requires stricter resource management policies while we are still
using forward goto. This is very simple case, for those application
heavenly depend on STL, exception is inevitably. In fact, you are
easily (mis)guided to use exception. What an error is a common mistake
or an exception highly depends. Without support of an exception
architecture, debug such application is time consuming. that why I
need the file name and line number of at where exception throw. As you
said, the things get more complex in a multithread environment.
As a result, I always found that some general accepted C++ programming
rules, proven as the story goes, just cannot be used indeed unless you
are doing something new from scratch. The chance is rare for most of
industrial programmers. Exception is one, DBC is another.
Anyway, I'm optimistic for this. RAII based resource management and
exception help me more. What I concent is why there is few related
materials on this, either online or offline? Too simple to say,
unrecommend practice indeed, has less experiences or something else?
Thank you
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]