rather poorly chosen). OP doesn't need, nor likely want, exceptions.
"Ups" <upendra.desai@gmail.com> wrote
try
{
fp = fopen(ConvertBSTRToString(m_bstrFileName), "r");
}
catch(_com_error &e)
{
return Error(e.Description().copy(), IID_IPacketReader, e.Error());
}
where m_bstrFileName is of type CComBSTR. If I return a new error
object so that my client can catch it, should I do perform
e.Description().copy() OR just e.Description() in the CComCoClass Error
function? What concerns me is the fact that my BSTR could leak memory.
It would. The COM error object keeps track of it itself. If you do the
Copy() you'll indeed leak memory.
Secondly, if I do not handle the exception here, would it get
propagated to the client's try...catch automatically. I am under the
impression that for a client to catch a _com_error exception, the
server will need to return a HRESULT with some error code. In this
case, the function does not return a HRESULT.
I'm afraid, I don't quite understand. The client is obviously in a
different process. I don't see how the exception could be propagated.
Anyway, Visual C++ implements exceptions via OS Exceptions (SEH).
COM rules clearly say that SEH are not allowed to cross interface
boundaries. So if marshaling code is involved it will typically swallow
C++ exceptions and translate these to client/server fault HRESULTs.
A good way to deal with that is insert guards at your entry points.
These are all functions exposed to external objects. Typically, I
have some macros
BEGIN_COM_METHOD_GUARD() and
END_COM_METHOD_GUARD()
which effectively translate to
CComMethodGuard<this_t> _guard_(*this);
try {
// function body
} catch ( const exception_type_1& xcpt ) {
return _guard_.MarshalCplusplusException(xcpt);
} catch ( const exception_type_2& xcpt ) {
return _guard_.MarshalCplusplusException(xcpt);
}
where CComMethodGuard<>::MarshalCplusplusException
just call the Error() method and returns the corresponding HRESULT.
-hg