Re: logfile msg: get method and class names
On Jan 29, 11:38 am, mfc <mfcp...@googlemail.com> wrote:
Hi,
I`ve a logfile which should contain all errors which can occur in the
programm. My document-class (SDI application) will contain a member-
variable of my logfile-class. If a error occurred in a different
thread than the mainthread I will write a PostMessage() to the window
I`ve installed for the document.
Why? This seems too complex and breaks the order of events. Just wrap
actual logging code into a synchronized block. Logging is one of
lowest-level operations there are, so there's no danger of deadlocking
(if there is, it is going be easy to weed out). You also might want to
make logging a non-throwing operation.
It would be great if the logfile will contain the information: class-
name, method-name, function-call with the specific GetLastError() if
available. Are there any methods to get the class name as well as the
method name where the error occurred? So that I immediately know where
the error occured if I see the logfile.
void MyThreadClass::MyMethod()
{
int rtn = Methodcall()
if(rtn != SUCCESS)
{ /* failed -> send msg to logfile */
DWORD err = ::GetLastError();
CString *perr = new CString();
perr->Format(_T("%s | %s | %s - %s"), classname, methodname,
call, err);
/* example:
perr ("MyThreadClass | MyMethod | Methodcall -
20(GetLastError) ")
*/
if(m_wnd)
m_wnd->PostMessage(UWM_LOGFILE_MSG, (WPARAM)perr,
(LPARAM)0);
}
}
Another method is to install thousands of defines (each possible error
will get one of these defines).... but that`s not really a good idea,
because it`s hard to update....
Are there any other options to determine where the error (located in
the logfile) occurred?
You could try __FILE__, __LINE__, __FUNCTION__. Alternatively, just
don't use same message text in two places, and you'll know the place
where error occurred by virtue of text being unique.
Note that, for low-level routines, that are called from many places,
even if the log shows exactly what went wrong, you often don't have
enough context to know __WHY__ (which is arguably more important than
"what"). To get that, you'll probably need to add more logs as you go
up the stack, or something like that.
e.g (I am exaggerating for the purpose of the example; you'll need to
balance the pain and the usefulness of consistently doing what
follows).
bool f1()
{
if (!op())
{
log(failure explanation);
return false;
}
}
bool f2()
{
op1;
op2
op3
if (!f1)
{
log(f2-specific failure explanation)
return false;
}
}
bool f3()
{
op4
op5
if (f2())
{
log(f3-specific failure explanation)
return false;
}
}
Goran.
P.S. "return bool" is for the sake of example. He who uses bool for
error-return in C++ these days, should probably be banned from coding.