Exception and GetLastError()

Hi there:
look at code blow
////////////////////
try
{
blah blah blah
}catch(...)
{
DWORD dw = GetLastError()
}
////////////////////

Does it make sence to call GetLastError() in catch block?
In my opinion, I dont think it's necesary do like above, but could sure
about it.

William
Mon Jul 23 10:57:08 CDT 2007

"hangaround" <hangaround@discussions.microsoft.com> wrote in message
news:C86528AA-24C4-4AA5-90AB-30A7FA0064A3@microsoft.com...
> Hi there:
> look at code blow
> ////////////////////
> try
> {
> blah blah blah
> }catch(...)
> {
> DWORD dw = GetLastError()
> }
> ////////////////////
>
> Does it make sence to call GetLastError() in catch block?
> In my opinion, I dont think it's necesary do like above, but could sure
> about it.

There is not enough information to say with certainty if the last error
would be meaningful at all. That's because some functions do not clear the
error code in advance and in the case where the function succeeds the value
is stale.

Regards,
Will

SvenC
Mon Jul 23 11:00:15 CDT 2007

Hi,

> look at code blow
> ////////////////////
> try
> {
> blah blah blah
> }catch(...)
> {
> DWORD dw = GetLastError()
> }
> ////////////////////
>
> Does it make sence to call GetLastError() in catch block?
> In my opinion, I dont think it's necesary do like above, but could sure
> about it.

No, it does not make sense. Win32-APIs which use GetLastError to return
error situations do not throw exceptions, so there should be no relationship
between some code triggering an exception and a Win32-API trying to give you
error information.

Try to avoid general catch(...)-handlers as you only blindly hide program
faults. Take crashes as a chance to find the reason for the error and fix
it. If you want to catch any error to do some error logging you should put a
throw; at the end of the catch block so that the exception is rethrown and a
debugger or DrWatson can catch an report it, e.g. as a mini dump. If you
have debug symbols for all your modules you might find the cause of the
error by opening such a mini dump in a debugger.

--
SvenC

hangaround
Mon Jul 23 11:26:05 CDT 2007



"SvenC" wrote:

> Hi,
>
> > look at code blow
> > ////////////////////
> > try
> > {
> > blah blah blah
> > }catch(...)
> > {
> > DWORD dw = GetLastError()
> > }
> > ////////////////////
> >
> > Does it make sence to call GetLastError() in catch block?
> > In my opinion, I dont think it's necesary do like above, but could sure
> > about it.
>
> No, it does not make sense. Win32-APIs which use GetLastError to return
> error situations do not throw exceptions, so there should be no relationship
> between some code triggering an exception and a Win32-API trying to give you
> error information.
>
> Try to avoid general catch(...)-handlers as you only blindly hide program
> faults. Take crashes as a chance to find the reason for the error and fix
> it. If you want to catch any error to do some error logging you should put a
> throw; at the end of the catch block so that the exception is rethrown and a
> debugger or DrWatson can catch an report it, e.g. as a mini dump. If you
> have debug symbols for all your modules you might find the cause of the
> error by opening such a mini dump in a debugger.
>
> --
> SvenC
>

mimi dump?
Could you please give a sample about this?

SvenC
Mon Jul 23 11:42:45 CDT 2007

Hi,

>>> look at code blow
>>> ////////////////////
>>> try
>>> {
>>> blah blah blah
>>> }catch(...)
>>> {
>>> DWORD dw = GetLastError()
>>> }
>>> ////////////////////
>>>
>>> Does it make sence to call GetLastError() in catch block?
>>> In my opinion, I dont think it's necesary do like above, but could sure
>>> about it.

>> Try to avoid general catch(...)-handlers as you only blindly hide
>> program faults. Take crashes as a chance to find the reason for the
>> error and fix it. If you want to catch any error to do some error
>> logging you should put a throw; at the end of the catch block so that
>> the exception is rethrown and a debugger or DrWatson can catch an
>> report it, e.g. as a mini dump. If you have debug symbols for all your
>> modules you might find the cause of the error by opening such a mini
>> dump in a debugger.
>
> mimi dump?
> Could you please give a sample about this?

Take a look at http://www.microsoft.com/whdc/devtools/debugging/default.mspx
to get information about the debugging SDK.
Mini dumps are snap shots of parts of a processes memory, like the call
stacks of the current threads and maybe also parts of the heap.

DrWatson does write those dumps. Use drwtsn32 -i to set it as debugger and
drwtsn32 to configure some parameters like which directory to use to write
the dump files to.

Those dump files (usually with an extension of dmp, mdmp, udmp or hdmp) can
be loaded with windbg from the debugging sdk so that you can analyze the
state of a process when an exception occurs.

You can also use MiniDumpWriteDump to create dump files programmatically. It
is alos describer in the debugging SDK.

Those dumps depend heavily on debug symbols, so be sure to create all
modules (dll, ocx and exes) with debugging symbols (pdb files). Microsoft
provides them with their public symbol server (also described in the
debugging sdk).

--
SvenC

Alex
Mon Jul 23 13:37:50 CDT 2007

In addition to Sven's answer, here's good article about
minidumps:

"Post-Mortem Debugging Your Application with Minidumps and
Visual Studio .NET"
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp


Alex