Thanks for the feedback:
The only way that GetLastWin32Error is going to return a different value
is if you use another call to unmanaged code. You should store the error
if you are going to perform an operation which could possibly change it,
and you need it for later.
I won't be calling unmanaged code directly. My concern are calls that .NET
itself makes. Those calls will invoke "SetLastError()" in the WinAPI but
does this affect "Marshal.GetLastWin32Error()" for clients (i.e., me). Note
that I can always save the result before throwing the exception (passing
this value to the constructor) but I'd like to know what the rules are.
I am curious, why are you passing an error string or the last error to the
Win32Exception class? If you use the default constructor, it should get
the value of the last win 32 error and also create the appropriate
exception message.
I'm still experimenting but I want to capture context info at the time of
call (the parameters that caused the failure for instance). Take this as a
possible solution for example (which I'm still considering):
class Win32LastError : Win32Exception
{
public Win32LastError(string messageEx)
{
m_MessageEx = messageEx;
}
public string MessageEx
{
get
{
return m_MessageEx;
}
}
private string m_MessageEx;
}
When the base class' default constructor is called, could the last error
have already been overwritten during construction of the "messageEx"
parameter itself (in the above constructor). It relies on the WinAPI behind
the scenes so it could potentially change the last error before the base
class constructor even starts (or so I'm speculating). This would be
particularly true if a non-trivial expression is used to create the string
in the first place (at the point of call). Note that this won't involve
unmanaged code however.
