Prev: Unable to Inherit Semaphore Handle
Next: Delay between parent window resize/paint and child window resize
From: peter01242 on 16 Dec 2009 11:47
I am trying to implement some exception trapping code in a product. If
I 'force' an access violation exception in the DLL, the VC6 debugger
can see the exception being generated, but it fails to materialise if
I wrap LoadLibrary in a try ... catch block. All I get is the
LoadLibrary call failing with GLE=998. Is it possible to get this info
so that I can 'trap' it in the calling app?


From: David Schwartz on 19 Dec 2009 21:45
On Dec 16, 8:47 am, peter01242 <peter01...(a)gmail.com> wrote:

> I am trying to implement some exception trapping code in a product. If
> I 'force' an access violation exception in the DLL, the VC6 debugger
> can see the exception being generated, but it fails to materialise if
> I wrap LoadLibrary in a try ... catch block. All I get is the
> LoadLibrary call failing with GLE=998. Is it possible to get this info
> so that I can 'trap' it in the calling app?

I think this is a poor design choice. Instead of generating an
exception and trying to catch it, just have the application call a
'get status' function in the DLL and have the DLL succeed in its
intialization.

An application and the DLLs it calls necessarily cooperate. You should
not treat this as a hostile environment. If you need to do that, wrap
the DLL in its own process, and catch the failure of that process.

DS
 | 
Pages: 1
Prev: Unable to Inherit Semaphore Handle
Next: Delay between parent window resize/paint and child window resize