Handled exceptions causing application to terminate

[Matt Lowe]

Hi, genius-type people.

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(...) {}
}

[Remy Lebeau (TeamB)]

Post by Matt Lowe
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.

Post by Matt Lowe
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.

Post by Matt Lowe
The functions are dynamically loaded by a VB plugin for ESRI's ArcGIS.

VB can't handle VC++ or BCB exceptions at all.

Post by Matt Lowe
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.

Post by Matt Lowe
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.

Post by Matt Lowe
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]

Post by Remy Lebeau (TeamB)

Post by Matt Lowe
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.

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]]

Post by Matt Lowe
Hi, genius-type people.

Are you talking to me? Hello!
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

[Matt Lowe]

Post by Alex Bakaev [TeamB]
Are you talking to me? Hello!

Well obviously!

Post by Alex Bakaev [TeamB]
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.

[Alex Bakaev [TeamB]]

Post by Matt Lowe
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?

[Matt Lowe]

Thanks again for your help.

Post by Alex Bakaev [TeamB]
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]]

Post by Matt Lowe
Thanks again for your help.

Post by Alex Bakaev [TeamB]
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]

Post by Alex Bakaev [TeamB]
Is there a second version of the DLL lurking somewhere?

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.

[Remy Lebeau (TeamB)]

Post by Matt Lowe
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]]

Post by Remy Lebeau (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.

[Remy Lebeau (TeamB)]

Post by Matt Lowe
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]

Sorry, I posted between builds and had taken it off in the cpp file.

Post by Remy Lebeau (TeamB)
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.