This page is a place to store all of the information that I am gathering about C++ exceptions for Pocket PC 2002 and later. My goal is to come up with the best system to support error handling on eVC3 and eVC4. My ideal goal is to be able to handle 100% of all errors - at least to the level that I can on Windows XP. Without exceptions can I really use operators and constructors?
As far as I am aware I have three types of exceptions on Pocket PC.
Here is an excellent article on the implementation of exception handling titled How a C++ compiler implements exception handling
Here is an article titled A Crash Course on the Depths of Win32™ Structured Exception Handling
__except, RaiseException
TRY/CATCH macros which I believe use setjmp/longjmp. The problem here is that the destructors do not get called which results in a resource leak. I believe the stack frame may also not get released.
Here's a Q&A at an MSDN RSS site:
Had a few QFEs to install, so more down time while I create an updated image, so on to the recent questions I've gotten through feedback! The first question was from Mike Dimmick: “will the next version of MFC/CE use C++ exceptions, rather than the old MFC setjmp/longjmp version?“. The answer is yes the next version of MFC for Windows CE will use C++ exceptions instead of the old MFC setjmp/longjmp imitation exceptions.
The next question was, also from Mike, is “I guess [the question of whether the next version of MFC for Windows CE will use C++ exceptions] is a tough question, because some OEMs may not wish to include C++ exception support in their platform - but aren't C++ exceptions required for .NET CF anyway?”. The answer to this is yes, the next version of the .NET Compact Framework will require C++ exceptions, as they are utilized in the new COM interop support being provided in the next version. It's my understanding that the current version of the .NET Compact Framework does not require C++ exceptions, because it does not have the COM interop support.
The subject of the C and C++ compiler helper functions and the C Runtime being built into the OS is the subject of some debate internally here at Microsoft. Ideally, in my opinion, none of these APIs would be built into the OS, so that developers could utilize whatever the latest version is that is compatible with the version of the OS they want to target; however, because much of this is currently built into coredll.dll, there are some potential technical barriers to moving these APIs in to our standalone C/C++ runtimes. One option we are considering is including all of the C++ EH and C++ RTTI helper functions in our standalone C/C++ runtimes, but there is currently an issue of link order. If coredll.lib is first then the APIs will get imported from coredll.dll, but if msvcrt.lib is first, then the APIs will get imported from msvrt80.dll (or optionally libcmt.lib if linking statically); however, the linker may throw an error if two import libs have the same APIs, I know it’s okay for static libs, but I haven’t had a chance to check what happens for import libs.
From USENET
Compiler throws errors because it doesn't understand C++ language. When you use something unavailable on the target platform it is generally the linker who complains. For example exceptions will cause linker error about not found __CxxThrowException and __CxxFrameHandler. (btw it is quite possible to implement these by yourself and have exceptions on PPC02 too)
Function prototypes appear to be
void __stdcall _CxxThrowException(void *,struct _s__ThrowInfo const *)
From another USENET posting:
The implementation of CxxThrowException:
#define CXX_FRAME_MAGIC 0x19930520
#define CXX_EXCEPTION 0xe06d7363
NTSYSAPI
VOID
NTAPI
RtlRaiseException (
IN PEXCEPTION_RECORD ExceptionRecord
);
VOID
NTAPI
RaiseException (
IN ULONG ExceptionCode,
IN ULONG ExceptionFlags,
IN ULONG NumberParameters,
IN CONST ULONG_PTR *ExceptionInformation
)
{
EXCEPTION_RECORD ExceptionRecord = {
ExceptionCode,
ExceptionFlags & EXCEPTION_NONCONTINUABLE,
NULL,
RaiseException,
NumberParameters > EXCEPTION_MAXIMUM_PARAMETERS ?
EXCEPTION_MAXIMUM_PARAMETERS : NumberParameters
};
RtlCopyMemory(
ExceptionRecord.ExceptionInformation,
ExceptionInformation,
ExceptionRecord.NumberParameters * sizeof(ULONG_PTR)
);
RtlRaiseException(&ExceptionRecord);
}
VOID
NTAPI
_CxxThrowException (
IN PVOID Object,
IN PVOID CxxExceptionType
)
{
ULONG_PTR ExceptionInformation[3];
ExceptionInformation[0] = CXX_FRAME_MAGIC;
ExceptionInformation[1] = (ULONG_PTR) Object;
ExceptionInformation[2] = (ULONG_PTR) CxxExceptionType;
RaiseException(
CXX_EXCEPTION,
EXCEPTION_NONCONTINUABLE,
3,
ExceptionInformation
);
}