Re: Exception is not caught in RELEASE mode
On Mon, 08 Oct 2007 08:26:17 -0700, Uwe Kotyczka <uwe.kotyczka@web.de>
wrote:
Well, I do have the third parties source code, but I would like to
modify it as less as possible. At several places (f.e. if some memory
allocations fails) it contains some very ugly "exit(1)"s, which are
not
acceptible in my GUI program. So I thought that throwing an exception
instead
would be a good idea. Didn't know that throwing exceptions from extern
"C"
functions is unusual.
What would you think to be a good replacement for the "exit(1)"
statements?
I don't know. If you replace exit() with throw, do you shut down the
program when you catch the exception? If you don't, the implication is that
you can still use the DLL which wanted to exit(). If the DLL's state is so
messed up that it cannot be called into again, you have a problem. At the
very least, you can probably expect memory and other resource leaks
depending on which exit() gets short-circuited.
Assuming that it's reasonable to replace exit() with throw, you could
expose two APIs from the DLL, a C++ API that propagates exceptions, and a C
API that translates exceptions into return codes.
Note that when passing C++ objects such as exceptions between modules, you
should consider the dynamic linking equivalent to static linking WRT
compilation dependencies. This means all affected modules should use the
same CRT DLL, they should be compiled with the same compiler (the version
and service pack should agree), and so forth. Heck, there's no standard for
implementing C++ exceptions, so even if you're throwing ints, I think this
applies.
--
Doug Harrison
Visual C++ MVP