Re: IErrorInfo question
"Ups" <upendra.desai@gmail.com> wrote
Thanks everyone,
I guess I could use CW2A to convert the CComBSTR to char *.
Always keep in mind that char* alone is not necessarily a complete
description of text. You still need the encoding. The thread locale,
which is typically derived from the user default locale is not what
you want in all cases.
What I am still not clear is about the exception handling. If I wanted
to return an exception caught by my ATL Server (lets say I want to
catch exceptions from another COM object that my ATL server uses), how
does the string handling there work.
try
{
//some code here
....
}
catch(_com_error &e)
{
return Error(e.Description().copy(), IID_IPacketReader,
e.Error());
}
As Holger suggested, "copy()" will actually leak memory. If that is the
case, do I just use e.Description() or do I do something like...
e.Description() returns a temporary. This temporary is destroyed
after the evaluation of the full statement. Once, the evaluation is
complete the temporary is destroyed. The implementation of
_bstr_t will manage memory for you.
Error takes a BSTR which need only be valid during that call.
So you can do:
Error(e.Description(),...);
because this is a single statement. The simplified execution order is
- Invoke e.Description()
- bstr_t-to-BSTR conversion
- Invoke Error
- Destroy temporary (calls the dtor)
But you cannot do:
BSTR bstrDescr = e.Description(); // assign - invokes dtor
Error(bstrDescr,..);
catch(_com_error &e)
{
//Assign the description to a local CComBSTR so that we
do not have to
//worry about the "Description" string in the
_com_error object.
CComBSTR bstrError = e.Description();
return Error(bstrError.copy(), IID_IPacketReader,
e.Error());
Just adds another copy and free. There's no point in doing so.
BTW Holger, are you saying that I cannot use IErrorInfo (_com_error) to
propagate errors if the server is an out-of-process EXE server? I might
try this out quickly by writing a quick VB client. If this is the case,
I will have to work out something else to pass on exceptions (as you
suggested).
The error information contained in the thread error object (IErrorInfo)
will be marshalled by the COM handlers. However, you cannot throw
raw C++ exception - regardless of type - across process boundaries,
and in fact across any marshaled COM boundary.
The process of translating _com_error to COM exception information
is exactly what you do with the catch clause above.
Also, do be aware that you should handle ATL Exceptions, too if you
use any ATL functionality such as CW2A & friends. Alternatively,
you can adjust both the ATL and the compiler COM support frameworks
to provide your own exception classes.
-hg