Handled exceptions causing application to terminate
Matt Lowe
I have two nearly identical DLLs, one created in VS C++, and one created in
RAD studio. They each export a function that throws a handled exception. The
functions are dynamically loaded by a VB plugin for ESRI's ArcGIS.
Here's the strange thing: when I call the function ThrowHandledException()
from the VS DLL inside the VB code, everything works fine. When I call the
function from the RAD studio DLL, the host app terminates, as I would expect
it to do if I threw an *unhandled* exception across a C interface.
Anybody know what might be going on here? The code looks like this:
extern "C" {
void __declspec(dllexport) _stdcall ThrowHandledException();
}
void ThrowHandledException()
{
try { throw 123; } catch(...) {}
}
--
Matt Lowe
Milsoft Utility Solutions
Remy Lebeau (TeamB)
"Matt Lowe" <leavem...@milsoft.com> wrote in message
news:483ebf61$1...@newsgroups.borland.com...
> I have two nearly identical DLLs, one created in VS C++,
> and one created in RAD studio.
BCB cannot handle VC++-generated exceptions, and vice versa.
> They each export a function that throws a handled exception.
NEVER allow an exception to pass over the DLL boundary from the DLL into the
app and vice versa. They may not know how to handle each other's
exceptions, especially if they are written in different
languages/environments.
> The functions are dynamically loaded by a VB plugin for ESRI's ArcGIS.
VB can't handle VC++ or BCB exceptions at all.
> when I call the function ThrowHandledException() from the VS DLL
> inside the VB code, everything works fine.
I doubt it, since VB can't handle C++ exceptions.
> When I call the function from the RAD studio DLL, the host app terminates,
> as I would expect it to do if I threw an *unhandled* exception across a C
> interface.
You are throwing an exception the BCB app can't actually handle.
> Anybody know what might be going on here?
You have a bad DLL design that is doing things it should not be doing in the
first place.
Gambit
Matt Lowe
>
> NEVER allow an exception to pass over the DLL boundary from the DLL into
> the app and vice versa. They may not know how to handle each other's
> exceptions, especially if they are written in different
> languages/environments.
Maybe I'm misunderstanding what you're saying here. If you look at the code
I posted, you'll see that the exception is thrown *and handled* within the
DLL, and should not be passed up to the client app:
void _stdcall ThrowHandledException()
{
try { throw 123; } catch(...) {}
}
But the app still crashes.
![Alex Bakaev [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWHNrNVRl-Kg9ouStjpvYWtzlbqdUvLKTbXnzCabkpiJjY-pg=s40-c)
Alex Bakaev [TeamB]
> Hi, genius-type people.
Are you talking to me? Hello!
>
> Anybody know what might be going on here? The code looks like this:
Can you debug the DLL? I.E., use the VB app as a host to debug the BCB
DLL, set your breakpoints and let it rip.
.a
Remy Lebeau (TeamB)
> extern "C" {
> void __declspec(dllexport) _stdcall ThrowHandledException();
> }
>
> void ThrowHandledException()
> {
> try { throw 123; } catch(...) {}
> }
You did not include _stdcall in the implementation code:
extern "C" {
void __declspec(dllexport) __stdcall ThrowHandledException();
}
void __stdcall ThrowHandledException()
{
try { throw 123; } catch(...) {}
}
Asside from that, do you have exception handling enabled in the BCB DLL
project to begin with?
Gambit
Matt Lowe
Well obviously!
> Can you debug the DLL? I.E., use the VB app as a host to debug the BCB
> DLL, set your breakpoints and let it rip.
Um, I thought I could. Now it attaches to the executable, but I never see
breakpoints in the DLL. Oddly enough, I have another DLL I'm using the same
way that seems to debug fine ... gr.
Matt Lowe
Sorry, I posted between builds and had taken it off in the cpp file.
> Asside from that, do you have exception handling enabled in the BCB DLL
> project to begin with?
Yes. I have tried mucking with lots of project options, but nothing seems to
affect this particular behavior.
Alex Bakaev [TeamB]
> Um, I thought I could. Now it attaches to the executable, but I never see
> breakpoints in the DLL. Oddly enough, I have another DLL I'm using the same
> way that seems to debug fine ... gr.
>
Is the .tds file present in the same folder as the DLL?
Remy Lebeau (TeamB)
> Um, I thought I could. Now it attaches to the executable,
> but I never see breakpoints in the DLL.
The EXE, DLL, and TDS files should be in the same folder.
Gambit
Alex Bakaev [TeamB]
> The EXE, DLL, and TDS files should be in the same folder.
>
>
I don't think the host .exe needs to be in the same folder. I.E., one
can debug a shell extension by attaching to the explorer.exe, which is
located who knows where.
Matt Lowe
> Is the .tds file present in the same folder as the DLL?
Yes, the dll and its tds file are in the same folder. The event log displays
the load of my DLL, but it says there's No Debug Info. I have a DLL that's
attached in the exact same way that I *can* still debug into, so I'm not
sure what the difference is. I'll bang on it some more.
Alex Bakaev [TeamB]
> Thanks again for your help.
>
>> Is the .tds file present in the same folder as the DLL?
>
> Yes, the dll and its tds file are in the same folder. The event log displays
> the load of my DLL, but it says there's No Debug Info. I have a DLL that's
> attached in the exact same way that I *can* still debug into, so I'm not
> sure what the difference is. I'll bang on it some more.
>
Is there a second version of the DLL lurking somewhere?
Matt Lowe
No, which really confuses me.
Now I have two DLLs that are identical except for their names, and I can
debug into one but not the other. Maybe I'm somehow using them differently
in the client app. I'm going to try breaking the one that works now, maybe
that will clue me in.