WriteFile(...) exception

[VladimirF]

...Evidently my search yielded some results that are not fully appropriate for the MFC environmet.

So what should I use to open and write a text based log file?

CStdioFile

[Paul McKenzie]

So what should I use to open and write a text based log file?

CreateFile and WriteFile are the common functions to use to create and write a file in Windows OS. MFC has specialized classes that wrap this functionality such as CFile and CStdioFile, so CStdioFile would be the best bet.

And of course, you have the general C++ functions such as ifstream/ofstream, as well as fopen/fclose, but remember that these are standard C++ functions -- meaning they do not have all the bells and whistles of the Windows API and MFC classes/functions.

Regards,

Paul McKenzie

[bkelly]

Well, CreateFile and WriteFileWindows API should (I'd say must) work good if you used them right.
What exactly is your problem? Why don't you want to show your actual code producing the problems?
Did you try something with SEH as Paul suggested?

Structured Exception Handling:
Yes, I am looking at that. but, for example, the declaration for WriteFile does not say anything about any exceptions so I still don't know what to do in the catch handler to determine the source of a problem.

Switching to topic CreateFileA() and WriteFile()

Well, they are working now. Reading this thread and thinking about the posts led me to the errors in my code.

That done, I have several classes and now need to log data from multiple classes. That means I need extract my logging code, that started out simple, to a new class that is accessible to several classes so I can coordinate the logging data.

Now that I am doing that, I am wondering if I have selected the right tool for this job. As noted earlier, even a search that specified "mfc C++" turned up options that are not appropriate for MFC. I don't have any co-workers that have that knowledge, so here I am.

Given all the above, Windows XP Pro, soon migrating to Windows 7, Visual Studio 2008, MFC, C++:

What is the best tool to use for writing a text based log file?

[Paul McKenzie]

Structured Exception Handling:
Yes, I am looking at that. but, for example, the declaration for WriteFile does not say anything about any exceptions so I still don't know what to do in the catch handler to determine the source of a problem.

The WriteFile() function doesn't have to say anything about exceptions because WriteFile doesn't throw any exceptions.

For example, here is a function:

void foo(char *p)
{
     *p = 'x';
}

What if you pass an invalid pointer to foo()? What will happen? The foo function throws no exceptions, as you don't see the throw keyword used anywhere. The system exception that may occur would be a memory access violation. Those exceptions are called system exceptions -- they are not to be confused with general C++ exceptions.

So you cannot just look at the traditional try/catch that C++ provides, since they are meant to catch C++ exceptions. A C++ exception is one where the function you're calling actually throws an exception using the throw keyword. My foo() function doesn't throw exceptions, and neither does WriteFile, so it would be erroneous for WriteFile to mention anything about exceptions being thrown.

Structured Exception Handling (SEH) is a topic that is a different issue altogether. A Structured Exception is not a C++ topic, it is a Windows OS topic. Please read fully what Structured Exceptions are, and how to handle them. What programmers will do is set up the SEH, and then from that SEH handler, throw a real C++ exception using the throw keyword. Also, Visual C++ introduced keywords (I've never used them) that handle these types of exceptions, different than try/catch:

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

Regards,

Paul McKenzie

[bkelly]

RE: So you cannot just look at the traditional try/catch that C++ provides, since they are meant to catch C++ exceptions. A C++ exception is one where the function you're calling actually throws an exception using the throw keyword. My foo() function doesn't throw exceptions, and neither does WriteFile, so it would be erroneous for WriteFile to mention anything about exceptions being thrown.


Ok, that was a learning moment. I now understand that when I called the WriteFile() and wound up in an unhandled exception environment (running the program from within the Visual Studio environment), that was because of my C/C++ fundamental error, and not the result of the WriteFile(). So putting a try/catch around WriteFile and its brethern has no merit.

So, that lesson learned, what should I use to create and write to a text based log file from within an MFC project?

[S_M_A]

There are some logging libraries on the net (google 'c++ logging library').

I've only used ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) but that might be to overcomplicate things. This http://www.pantheios.org/ or this http://log4cpp.sourceforge.net/ might be more lightweight versions.

[VictorN]

...
So, that lesson learned, what should I use to create and write to a text based log file from within an MFC project?

See the post#17.

[Paul McKenzie]

Ok, that was a learning moment. I now understand that when I called the WriteFile() and wound up in an unhandled exception environment (running the program from within the Visual Studio environment), that was because of my C/C++ fundamental error, and not the result of the WriteFile(). So putting a try/catch around WriteFile and its brethern has no merit.

Well, the problem is that you can do something like this:

try
{
   WriteFile(..);
}
catch(...)
{
    
}

And that could catch the system exception if you compile with the /EHa switch. However, the problem is the catch-all "..." phrase, as you don't know exactly what happened. So yes, you can catch the exception, but have little information as to what the exception is.

That's why IMO it's better to use the Visual C++ keywords I mentioned, or set up the SEH "the hard way", get the real error, and from your SEH, do a legitimate C++ throw with better information as to the error. These options do not need special compiler switches set to work.

See here:

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

Regards,

Paul McKenzie

[bkelly]

See the post#17.

In the flurry of posts I kept scrolling to the bottom, failed to look carefully, and missed that one.
Thank you.