Re: _ATL_NO_EXCEPTIONS conflict
On 25/06/2010 09:09, Goran wrote:
The online MSDN documentation appears wrong.
You cannot define _ATL_NO_EXCEPTIONS for MFC apps.
So no assertion failure for MFC projects, it wont even compile.
Well, isn't that entirely logical? MFC uses exceptions as a matter of
fact. Code that is shared between the two (e.g. CString) uses AtlThrow
to work with standalone ATL, MFC, or both. So if you're using MFC, you
are using the "MFC way" already. You are exploring a dead alley with
this.
I agree with Goran's analysis.
You can try _ATL_NO_EXCEPTIONS only without MFC, but, if I am not
mistaken, that will turn any calls to AtlThrow into structured
exception (IOW, a crash) in release builds.
That's correct (at least, this is how I knew it, too).
In fact, reading <atlexcept.h> in VS2010, in the preprocessor #else
branch related to the case of _ATL_NO_EXCEPTIONS defined:
<code>
....
#else // no exception handling
// Throw a CAtlException with th given HRESULT
#if !defined( _ATL_CUSTOM_THROW ) // You can define your own AtlThrow
ATL_NOINLINE inline void WINAPI AtlThrowImpl(_In_ HRESULT hr)
{
ATLTRACE(atlTraceException, 0, _T("AtlThrow: hr = 0x%x\n"), hr );
ATLASSERT( false );
DWORD dwExceptionCode;
switch(hr)
{
case E_OUTOFMEMORY:
dwExceptionCode = STATUS_NO_MEMORY;
break;
default:
dwExceptionCode = EXCEPTION_ILLEGAL_INSTRUCTION;
}
_AtlRaiseException((DWORD)dwExceptionCode);
}
#endif
</code>
And _AtlRaiseException is a function which calls RaiseException, which
in turn raises a structured exception.
> So (again, if I am not mistaken): forget _ATL_NO_EXCEPTIONS
> altogether, unless... Unless you stop using essentially most of C++
> altogether.
Forget _ATL_NO_EXCEPTIONS in MFC projects, but not in ATL projects.
ATL can work without C++ exceptions as well; and in case of
*exceptionally bad* error conditions, structure exceptions are raised,
which is just fine. Sure, this does not work if you mean exceptions as a
way to control program flow (stealing the job to 'if's :)
Giovanni