views:

364

answers:

6

Today, in my C++ multi-platform code, I have a try-catch around every function. In every catch block I add the current function's name to the exception and throw it again, so that in the upmost catch block (where I finally print the exception's details) I have the complete call stack, which helps me to trace the exception's cause.

Is it a good practice, or are there better ways to get the call stack for the exception?

+17  A: 

No, it is deeply horrible, and I don't see why you need a call stack in the exception itself - I find the exception reason, the line number and the filename of the code where the initial exception occurred quite sufficient.

Having said that, if you really must have a stack trace, the thing to do is to generate the call stack info ONCE at the exception throw site. There is no single portable way of doing this, but using something like http://stacktrace.sourceforge.net/ combined with and a similar library for VC++ should not be too difficult.

anon
I am talking about a large-scale project. This mechanism helped me many times to see the full flow that caused the exception. Why is it so horrible, if it saves me a lot of debug time?
Igor Oks
@Igor And the rest of us of course only work on small-scale projects? It may save you debug time (though if you spend much time debugging you have other problems) but it greatly reduces your code's maintainability and readability which (to me at least) are far more important.
anon
@Neil : For another point of view, I find stack traces indispensable. @Igor : To generate a stacktrace in gcc, http://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes , and I'm sure windows has something similar. At any rate, wrapping these blocks around every function really is "deeply horrible".
Stephen
Yes a stack trace is good, no building it yourself isn't maintainable. On Windows at least, when you catch an exception you call `GetExceptionInformation` which gives you a `CONTEXT` structure to pass to `StackWalk64`.
Ben Voigt
@Ben Voigt: Only if you use SEH, instead of /EHsc.
DeadMG
/EHa seems like a very small price to pay for stack traces.
Ben Voigt
@Ben The big price you pay is portability, which is a reqiurement in this case.
anon
True. How many locations in the code legitimately handle the exception will determine whether portability is a barrier to using these functions for stack traces in a cross-platform codebase. If there's just one master crash reporting routine, it'll be easy to develop a handful of OS-specific implementations, but if exception handling code is scattered all over, it's a serious concern.
Ben Voigt
+15  A: 

What you are doing is not good practice. Here's why:

1. It's unnecessary.
If you compile your project in debug mode so that debugging information gets generated, you can easily get backtraces for exception handling in a debugger such as GDB.

2. It's cumbersome.
This is something you have to remember to add to each and every function. If you happen to miss a function, that could cause a great deal of confusion, especially if that were the function that caused the exception. And anyone looking at your code would have to realize what you are doing. Also, I bet you used something like __FUNC__ or __FUNCTION__ or __PRETTY_FUNCTION__, which sadly to say are all non-standard (there is no standard way in C++ to get the name of the function).

3. It's slow.
Exception propagation in C++ is already fairly slow, and adding this logic will only make the codepath slower. This is not an issue if you are using macros to catch and rethrow, where you can easily elide the catch and rethrow in release versions of your code. Otherwise, performance could be a problem.

Good practice
While it may not be good practice to catch and rethrow in each and every function to build up a stack trace, it is good practice to attach the file name, line number, and function name at which the exception was originally thrown. If you use boost::exception with BOOST_THROW_EXCEPTION, you will get this behavior for free. It's also good to attach explanatory information to your exception that will assist in debugging and handling the exception. That said, all of this should occur at the time the exception is constructed; once it is constructed, it should be allowed to propagate to its handler... you shouldn't repeatedly catch and rethrow more than stricly necessary. If you need to catch and rethrow in a particular function to attach some crucial information, that's fine, but catching all exceptions in every function and for the purposes of attaching already available information is just too much.

Michael Aaron Safyan
To add to the "It's slow" case, it also prevents tail-position call optimizations by the compiler.
Hudson
Actually, the overhead if no exception actually occurs is normally pretty small, and if it does occur (which should be rare) typically is not very important.
anon
@Neil, I was referring to the case where an exception propagates.
Michael Aaron Safyan
There are zero-cost try implementations, I believe.
DeadMG
@DeadMG If so, I've never encountered one. A reference, please.
anon
@Neil: I've no idea. That's why I believe, rather than I know :P It's merely something that I heard.
DeadMG
@DeadMG: Urban legends are not worth repeating as it reinforces them with no facts. In the beginning C++ exceptions where slow (probably otherwise the myths would not have started) no doubt, but with modern compilers and computers I have never had a problem with speed that has caused my to doubt that exceptions were more than fast enough (and I work with highly scalable SOA were response times are very important). So though I have no proof either way I ignore mythes and will not consider exception speed a problem until I find an explicit case where it is.
Martin York
@Martin, exceptions are fast enough that they are worth using, but objects need to be destructed when exceptions propagate, so the speed of propagation can't be any faster than the destruction.
Michael Aaron Safyan
@Michael Aaron Safyan: The objects need to be destroyed weather exceptions are used or not. So this is a zero sum equation.
Martin York
A: 

The answer to all your problems is a good debugger, usually http://www.gnu.org/software/gdb/ on linux or Visual Studio on Windows. They can give you stack traces on demand at any point in the program.

Your current method is a real performance and maintenance headache. Debuggers are invented to accomplish your goal, but without the overhead.

Scott Stafford
Debuggers are great at solving reproducible problems. Intermittent bugs (especially those that occur in the field) are the ones where stack-traces are beneficial.
Oddthinking
Crash dump + debugger > stack trace
Ben Voigt
A: 

An exception that isn't handled is left for the calling function to handle. That continues until the exception is handled. This happens with or without try/catch around a function call. In other words, if a function is called that isn't in a try block, an exception that happens in that function will automatically be passed up to call stack. So, all you need to do is put the top-most function in a try block and handle the exception "..." in the catch block. That exception will catch all exceptions. So, your top-most function will look something like

int main()
{
  try
  {
    top_most_func()
  }
  catch(...)
  {
    // handle all exceptions here
  }
}

If you want to have specific code blocks for certain exceptions, you can do that too. Just make sure those occur before the "..." exception catch block.

zooropa
This doesn't solve the problem of how to generate a stack-trace to help work out *why* the exception was raised.
Oddthinking
You're right. Sorry about that. Check out my other answer.
zooropa
+1  A: 

Look at this SO Question. This might be close to what you're looking for. It isn't cross-platform but the answer gives solutions for gcc and Visual Studio.

zooropa
+2  A: 

One solution which may be more graceful is to build a Tracer macro/class. So at the top of each function, you write something like:

TRACE()

and the macro looks something like:

Tracer t(__FUNCTION__);

and the class Tracer adds the function name to a global stack on construction, and removes itself upon destruction. Then that stack is always available to logging or debugging, maintenance is much simpler (one line), and it doesn't incur exception overhead.

Examples of implementations include things like http://www.drdobbs.com/184405270, http://www.codeproject.com/KB/cpp/cmtrace.aspx, and http://www.codeguru.com/cpp/v-s/debug/tracing/article.php/c4429. Also Linux functions like this http://www.linuxjournal.com/article/6391 can do it more natively, as described by this Stack Overflow question: http://stackoverflow.com/questions/77005/how-to-generate-a-stacktrace-when-my-gcc-c-app-crashes. ACE's ACE_Stack_Trace may be worth looking at too.

Regardless, the exception-handling method is crude, inflexible, and computationally expensive. Class-construction/macro solutions are much faster and can be compiled out for release builds if desired.

Scott Stafford