Re: unexpected exception handler

From:

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Fri, 18 Jan 2008 07:59:43 -0600

Message-ID:

<#9CgtodWIHA.5596@TK2MSFTNGP05.phx.gbl>

"George" <George@discussions.microsoft.com> wrote in message
news:062C616F-8E67-4371-9B51-416ABDEDCC7B@microsoft.com...

Yes, Ben.

I always use HRESULT from COM API, like CoCreateInstance or something.
What
do you mean "COM Exception"?

That's what COM calls an "exception". There's the HRESULT along with
ISupportErrorInfo and IErrorInfo.

regards,
George

"Ben Voigt [C++ MVP]" wrote:

"George" <George@discussions.microsoft.com> wrote in message
news:EFA61E4E-A83B-42E9-99C1-7F797A7FA219@microsoft.com...

Sorry for my limited knowledge, Igor!

1. Do you mean COM/ATL API does not and should not throw any exception?

COM defines its own exceptions, which are not C++ exceptions and don't
use
C++ throw/try/catch statements. In fact, C and C++ programs see COM
exceptions as status codes (simple return value of type HRESULT). The
reason for this is that return values are well-supported by all compilers
and languages, while "true" exceptions aren't.

2. I keep my solution into separate DLLs and a single EXE which
utilizes
the
DLL for the reason of packaging and better upgrade, make them into
different
components.

3.

I think you mean DLL can not throw exception because there is no
binary standard in C++ means something designed in different
language/compiler. Right?:-)

I can't parse this statement. Doesn't look like well-formed English to
me, sorry.

Sorry for my bad description. What I mean is, you mentioned before that
if
DLL and EXE are using different compiler, it is not safe to let the
exported
API in DLL throw an exception and let the EXE catch it. The reason is
there
in no binary standard in C++, so no binary standard to describe an
exception
between the DLL and the EXE. Are my understanding of your points
correct?

have a good weekend,
George

"Igor Tandetnik" wrote:

"George" <George@discussions.microsoft.com> wrote in message
news:91977348-5041-4493-A88E-2837583E43A0@microsoft.com

1. The exceptions from other DLLs, samples are exceptions from ATL,
COM, etc. Is it correct sample?

What makes you believe ATL uses C++ exceptions? Can you cite any
evidence of this?

What makes you believe COM uses C++ exceptions? Can you cite any
evidence of this?

Are you just shooting up any odd three-letter acronyms you can think
of,
in hopes one of them sticks? I can't help but wonder what this line of
enquiry is supposed to achieve.

2. If I myself both write the DLL and the DLL consumer (application)
in the same compiler (Visual C++ and only in this language), could I
throw exception in the DLL exported API to application?

Yes, if you commit to always build both the EXE and the DLL with the
same version of the same compiler, and link both against the same
flavor
of CRT DLL. But if you do all this, it's not clear why you would want
to
package the code into two separate modules. Why not just compile all
code into a single EXE? The whole point of DLLs is binary reuse, but
by
using C++ exceptions in the DLL's interface you preclude precisely
that.

I think you mean DLL can not throw exception because there is no
binary standard in C++ means something designed in different
language/compiler. Right?:-)

I can't parse this statement. Doesn't look like well-formed English to
me, sorry.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925