ISupportErrorInfo question 
Author Message
 ISupportErrorInfo question

Hi

I use the "ISupportErrorInfo" interface in an Automation component I
developed. In "Debug" builds,  if the compoinent throws an error, I can
catch the error in a client VB application. I even get a pop-up error
message with the text of the exception I threw from the component.

My Problem: When I compile the component in "Release MinDependency", I
no longer get these error messages and the client application just
crashes (quits) without any warning whatsoever.

Is this normal? I'd like to know how to catch exceptions in Release
builds too.

Thanks
Alexandre Leduc



Sun, 28 Aug 2005 03:35:40 GMT  
 ISupportErrorInfo question
How exactly do you "throw an error"? You don't use C++ throw statement,
do you? You are supposed to return an error code from your method, like
this:

return Error("Error happened", IID_IMyInterface, E_MYERRORCODE);

That's just one of many overloads of CComCoClass::Error
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken


Quote:
> I use the "ISupportErrorInfo" interface in an Automation component I
> developed. In "Debug" builds,  if the compoinent throws an error, I
can
> catch the error in a client VB application. I even get a pop-up error
> message with the text of the exception I threw from the component.

> My Problem: When I compile the component in "Release MinDependency", I
> no longer get these error messages and the client application just
> crashes (quits) without any warning whatsoever.

> Is this normal? I'd like to know how to catch exceptions in Release
> builds too.



Sun, 28 Aug 2005 06:24:53 GMT  
 ISupportErrorInfo question
I checked "ISupportErrorInfo" in the ATL app wiward.

Than I wrapped every methos implementation's code like this:

try
{
        // the code where some exception may happen

Quote:
}

catch(_com_error& error)
{
TCHAR tstr[256] = {0};
wsprintf(tstr, _T("%s[%x]"), error.ErrorMessage(), error.Error());
Error(tstr, IID_ICheck);
hr = E_FAIL;
Quote:
}

catch(...)
{
TCHAR tstr[256] = {0};
wsprintf(tstr, _T("%s"), "Unhandled exception in this method");
Error(tstr, IID_ICheck);
hr = E_FAIL;

Quote:
}

This error handling works fine in the release version of some of the
components I created. It's just this specific component that has this
problem.

Alexandre LEduc

Quote:

> How exactly do you "throw an error"? You don't use C++ throw statement,
> do you? You are supposed to return an error code from your method, like
> this:

> return Error("Error happened", IID_IMyInterface, E_MYERRORCODE);

> That's just one of many overloads of CComCoClass::Error



Tue, 30 Aug 2005 05:48:48 GMT  
 ISupportErrorInfo question
What kind of exceptions are you catching in Debug build? Are they access
violations or other OS exceptions, by any chance? Bad things happen when
you try to catch OS exceptions with catch(...) clause. See

http://groups.google.com/groups?selm=fj540v85dhpguldn6b62hvcl6j3qr4nk...

--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken


Quote:
> I checked "ISupportErrorInfo" in the ATL app wiward.

> Than I wrapped every methos implementation's code like this:

> try
> {
> // the code where some exception may happen
> }
> catch(_com_error& error)
> {
> TCHAR tstr[256] = {0};
> wsprintf(tstr, _T("%s[%x]"), error.ErrorMessage(), error.Error());
> Error(tstr, IID_ICheck);
> hr = E_FAIL;
> }
> catch(...)
> {
> TCHAR tstr[256] = {0};
> wsprintf(tstr, _T("%s"), "Unhandled exception in this method");
> Error(tstr, IID_ICheck);
> hr = E_FAIL;
> }

> This error handling works fine in the release version of some of the
> components I created. It's just this specific component that has this
> problem.

> Alexandre LEduc


> > How exactly do you "throw an error"? You don't use C++ throw
statement,
> > do you? You are supposed to return an error code from your method,
like
> > this:

> > return Error("Error happened", IID_IMyInterface, E_MYERRORCODE);

> > That's just one of many overloads of CComCoClass::Error



Tue, 30 Aug 2005 06:10:08 GMT  
 ISupportErrorInfo question
Did you call _set_se_translator in order to convert non-C++ exceptions
in your code into C++ exceptions so you can catch them via C++ try/catch?
Sadly, the behavior is inconsistent if you don't do so...

You can also use __try/__except to catch SEH exceptions in the old C style.

Personally, I prefer not to catch SEH exceptions, so the underlying bugs get
fixed rather than covered...

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

Quote:

> I checked "ISupportErrorInfo" in the ATL app wiward.

> Than I wrapped every methos implementation's code like this:

> try
> {
> // the code where some exception may happen
> }
> catch(_com_error& error)
> {
> TCHAR tstr[256] = {0};
> wsprintf(tstr, _T("%s[%x]"), error.ErrorMessage(), error.Error());
> Error(tstr, IID_ICheck);
> hr = E_FAIL;
> }
> catch(...)
> {
> TCHAR tstr[256] = {0};
> wsprintf(tstr, _T("%s"), "Unhandled exception in this method");
> Error(tstr, IID_ICheck);
> hr = E_FAIL;
> }

> This error handling works fine in the release version of some of the
> components I created. It's just this specific component that has this
> problem.

> Alexandre LEduc


> > How exactly do you "throw an error"? You don't use C++ throw statement,
> > do you? You are supposed to return an error code from your method, like
> > this:

> > return Error("Error happened", IID_IMyInterface, E_MYERRORCODE);

> > That's just one of many overloads of CComCoClass::Error



Tue, 30 Aug 2005 06:11:35 GMT  
 ISupportErrorInfo question
I don't need to because at this point, the ISupportErrorInfo interface
manages the thrown error. Perhaps I haven't been clear enough. The com
server is where the exception is throw *and* caught. Then it sends
whatever error message was thrown with:

Error(tstr, IID_ICheck);

My client application is made in VB. In Debug builds of the COM server,
I get a pop-up in my VB client app with the error message that was
throw/caught in the COM server and then sent the client's way though
some COM error reporting method provided by the ISupportErrorInfo interface.

This is pretty standard ATL error handling. I learned this in a book
named "Beginning ATL 3 COM Programming".

Quote:

> Did you call _set_se_translator in order to convert non-C++ exceptions
> in your code into C++ exceptions so you can catch them via C++ try/catch?
> Sadly, the behavior is inconsistent if you don't do so...

> You can also use __try/__except to catch SEH exceptions in the old C style.

> Personally, I prefer not to catch SEH exceptions, so the underlying bugs get
> fixed rather than covered...



Tue, 30 Aug 2005 06:43:25 GMT  
 ISupportErrorInfo question
I'm not talking about your client - I'm talking about your component only.
You have try/catch, but this only catches C++ exceptions (0xE06D7363).
If you want to catch an AV for example (0xC0000005), you need the
_set_se_translator call.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

Quote:

> I don't need to because at this point, the ISupportErrorInfo interface
> manages the thrown error. Perhaps I haven't been clear enough. The com
> server is where the exception is throw *and* caught. Then it sends
> whatever error message was thrown with:

> Error(tstr, IID_ICheck);

> My client application is made in VB. In Debug builds of the COM server,
> I get a pop-up in my VB client app with the error message that was
> throw/caught in the COM server and then sent the client's way though
> some COM error reporting method provided by the ISupportErrorInfo interface.

> This is pretty standard ATL error handling. I learned this in a book
> named "Beginning ATL 3 COM Programming".


> > Did you call _set_se_translator in order to convert non-C++ exceptions
> > in your code into C++ exceptions so you can catch them via C++ try/catch?
> > Sadly, the behavior is inconsistent if you don't do so...

> > You can also use __try/__except to catch SEH exceptions in the old C style.

> > Personally, I prefer not to catch SEH exceptions, so the underlying bugs get
> > fixed rather than covered...



Tue, 30 Aug 2005 07:25:21 GMT  
 ISupportErrorInfo question
I don't try to catch any of those exceptions either. As a matter of
fact, I intentionally threw a regular C++ exception to test if it worked
and it didn't.

Alexandre Leduc

Quote:

> I'm not talking about your client - I'm talking about your component only.
> You have try/catch, but this only catches C++ exceptions (0xE06D7363).
> If you want to catch an AV for example (0xC0000005), you need the
> _set_se_translator call.



Tue, 30 Aug 2005 07:36:17 GMT  
 ISupportErrorInfo question

Quote:

> I'm not talking about your client - I'm talking about your component only.
> You have try/catch, but this only catches C++ exceptions (0xE06D7363).
> If you want to catch an AV for example (0xC0000005), you need the
> _set_se_translator call.

Or catch(...) (although I'd recommend using _set_se_translator).  But
either way, you MUST switch from /EHs[c] to /EHa.

--
Craig Powers
MVP - Visual C++



Tue, 30 Aug 2005 07:42:42 GMT  
 ISupportErrorInfo question

Quote:

> I checked "ISupportErrorInfo" in the ATL app wiward.

> Than I wrapped every methos implementation's code like this:

> try
> {
>         // the code where some exception may happen
> }
> catch(_com_error& error)
> {
> TCHAR tstr[256] = {0};
> wsprintf(tstr, _T("%s[%x]"), error.ErrorMessage(), error.Error());
> Error(tstr, IID_ICheck);
> hr = E_FAIL;
> }
> catch(...)
> {
> TCHAR tstr[256] = {0};
> wsprintf(tstr, _T("%s"), "Unhandled exception in this method");
> Error(tstr, IID_ICheck);
> hr = E_FAIL;
> }

> This error handling works fine in the release version of some of the
> components I created. It's just this specific component that has this
> problem.

You must compile with /EHa if you plan to catch OS exceptions in your
code.  Otherwise, the compiler optimizes the exception handling
machinery away if it sees that there is no throw statement.

Generally, I'd be wary of catching SEs in a component anyway, since
there's not typically anything useful you can do with them.

--
Craig Powers
MVP - Visual C++



Tue, 30 Aug 2005 07:45:43 GMT  
 ISupportErrorInfo question
Does a "catch(...)" catch OS exceptions? i.e. Does that catch statement
imply that I have to deal with them there?
Quote:
> You must compile with /EHa if you plan to catch OS exceptions in your
> code.  Otherwise, the compiler optimizes the exception handling
> machinery away if it sees that there is no throw statement.

> Generally, I'd be wary of catching SEs in a component anyway, since
> there's not typically anything useful you can do with them.



Wed, 31 Aug 2005 05:47:57 GMT  
 ISupportErrorInfo question
Otherwise, the compiler optimizes the exception handling

Quote:
> machinery away if it sees that there is no throw statement.

I just solved my problem. I notices that in my "Release MinDependency"
build:

Project Settings-> C/C++ Tab-> General-> Optimization

was set to Maximum Speed instead of Minimize Size (what I usually use).
Rebuilding my project that way corrected the situation.

Thanks everyone for your help.
Alexandre Leduc



Wed, 31 Aug 2005 05:57:07 GMT  
 ISupportErrorInfo question

Quote:

> Does a "catch(...)" catch OS exceptions?

It does.  It's generally agreed that this is not desirable for /EHs,
but even VC 7.1 does not fix this.  I'm not sure where the opinions
are on it for /EHa.

Quote:
> i.e. Does that catch statement
> imply that I have to deal with them there?

You should be aware of the occurrence and the consequences.  In
general, you should know what kinds of exceptions you'll need to
catch in your application anyway.  If you're not using MFC or the
like, there's potentially _com_error from imports and std::exception
derivatives from the C++ standard library, as well as anything you
throw in your own code.

--
Craig Powers
MVP - Visual C++



Wed, 31 Aug 2005 07:54:14 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. ISupportErrorInfo question.

2. ISupportErrorInfo Example

3. ISupportErrorInfo problems

4. ISupportErrorInfo - thread resurrection

5. How to work with ISupportErrorInfo ?

6. ISupportErrorInfo and VB

7. ISupportErrorInfo (manually)

8. help ISupportErrorInfo used on DLL runnig on server

9. ISupportErrorInfo Issue

10. ISupportErrorInfo with MTS

11. ISupportErrorInfo with MTS

12. implementing IErrorInfo and ISupportErrorInfo interfaces

 

 
Powered by phpBB® Forum Software