Try Catch

[PeterRod]

Problem with Try Catch

In my program I output a list of names to log.txt with this.

myfile << "\t"<< x << " Function name "<< FunctionName << "\n";

Sometimes an error occurs in the FunctionName and the file output TERMINATES but program execution continues.

A good line would be:
1 Function name CloseHandle

The file output at the critical line is
1 Function name
and file output terminates.

I don't know what the exception is. I dont really care I just want to trap it and move on.

so

Try
{
myfile << "\t"<< x << " Function name "<< FunctionName << "\n";
}
catch (...)
{
myfile << "\t" Unknown Function "\n";
}

Its my first time in C++ using Try Catch block.
I use them frequently in vb.net.
How do I catch any error / exception in the protected code?
I thought that catch (...) would catch any exception thrown by Windows?

Thanks for help!!1

[exception]

I don't know what the exception is. I dont really care

You should. In your case, what if the exception is related to the output code? Have fun in your catch block, then!

I thought that catch (...) would catch any exception thrown by Windows?

It catches *all* exceptions thrown in the try block.

My guess is that you use something ugly like a C string as FunctionName and that the pointer this string decays to points to a address in a segment you may not access... but that's just a guess. In that case, your program would be signaled with a segfault (or something like that, I'm not very familiar with Windows), which is not an exception and thus cannot be caught using a try...catch construct.

[PeterRod]

Thanks for your reply.

I am very, very new to C/C++ .

As a general rule, is try{ } catch(...) the recommended syntax for general type error trapping.
Or is there a better way?

I will revisit the earlier problem, but no CString variables are used.

[exception]

For me, handling exception is one of the most difficult programming problems. Nevertheless, C++ uses exceptions to report errors (and so should you when an error cannot be handled locally), so you have to deal with them. The exception mechanism is nod "good" or "bad" as it is, but it can be overused (or exception can be ignored alltogether, which might be even worse).
Guidelines for throwing:
- Use exceptions only to report errors, not as general control structures
- Throw exceptions only when the error cannot be handled locally
- Also throw exceptions in library code: the host application wants to control the user output (imagine std::vector would write something to std::cerr when an error occurs instead of throwing a std::out_of_range)
- Never allow an exception to leave a destructor

Guidelines for catching:
- Never allow an exception to leave a destructor
- Assume that an exception that can be thrown will be thrown
- When writing "real" applications, design for exception safe code - don't make it an "afterthought"
- Writing exception safe code doesn't mean 'try'-ing. Learn what code can throw and what the effects would be if an exception was thrown at any given location.

[Zaita]

Also a note on exceptions. They are extremely slow and have a high amount of overhead.

[PeterRod]

Great. will follow your advice