Steve McLellan wrote:
>
> "Vasco Lohrenscheit" <valohNOSPAM@web.de> wrote in message
> news:ceatqc$ads$1@online.de...
> > Hi,
> >
> > I have a Problem with unmanaged exception. In the debug build it works
> > fine to catch unmanaged c++ exceptions from other dlls with
> >
> > //managed code:
> > try
> > {
> > //the form loads unmanaged dlls out of which unmanaged exception //get
> > thrown
> > Application::Run(new Form1());
> > } catch (std::exception& e)
> > {
> > //catching work in debud build, in release build a SEHException
> > //gets thrown
> > }
> > But with the release build the same c++ exceptions are not catched but I
> > get a SEHException from the .net framework. Any idea what can cause this
> > Problem? I already checked build options and c++ exceptions are enabled
> > in the release build too, so the problem has to lie somewhere else...
> >
>
> I'm more surprised you get the std exception at all - all our unmanaged
> assertions get turned into SEHExceptions anyway. Try working out where the
> exception's coming from in the first place, and any differences in the
> compiler and linker settings between Debug and Release.
>
> Steve

"Vasco Lohrenscheit" <valohNOSPAM@web.de> wrote in message
news:ceatqc$ads$1@online.de...
> Hi,
>
> I have a Problem with unmanaged exception. In the debug build it works
> fine to catch unmanaged c++ exceptions from other dlls with
>
> //managed code:
> try
> {
> //the form loads unmanaged dlls out of which unmanaged exception //get
> thrown
> Application::Run(new Form1());
> } catch (std::exception& e)
> {
> //catching work in debud build, in release build a SEHException
> //gets thrown
> }
> But with the release build the same c++ exceptions are not catched but I
> get a SEHException from the .net framework. Any idea what can cause this
> Problem? I already checked build options and c++ exceptions are enabled
> in the release build too, so the problem has to lie somewhere else...
>

Julie wrote:

>
> That is what I was going to respond as well, but didn't because I didn't have a
> definitive answer.
>
> Sounds like your debug build is behaving incorrectly, and release is operating
> as it should.

"Vasco Lohrenscheit" <valohNOSPAM@web.de> wrote in message
news:ced6rk$avl$1@online.de...
> Julie wrote:
>
> >
> > That is what I was going to respond as well, but didn't because I didn't
have a
> > definitive answer.
> >
> > Sounds like your debug build is behaving incorrectly, and release is
operating
> > as it should.
>
>
> Does anybody has a definitive answer here?
>
> So unmanaged exception can't be catched in managed code? Well, thats
> really bad. Will this change with the standardised c++/CLI binding? Are
> there any possibilieties to extract the original unmanaged exception and
> its type from the SEHException?
>
> How do you handle unmanaged exceptions in managed code?
>

> Steve McLellan wrote:
>
> > Have a look at SEHException - it allows you to retrieve info related to
the
> > original exception (see MSDN for
> > System::Runtime::InteropServices::SEHException).
[snip]
>
> mhh, if I understand the section "Catching Unmanaged C++ Types"
> correctly, a catch(const std::exception& e) should work:
>
> " * If an unmanaged C++ type is encountered, the exception is
> unwrapped and compared to the type encountered. This comparison allows
> an unmanaged C++ type to be caught in the normal way.
> * However, if a catch clause of type SEHException or any of its
> base classes is examined first, the clause will intercept the exception.
> Therefore, you should place all catch clauses that catch unmanaged C++
> types first before any catch clauses of managed types.
> "
>
> After some testing I've found several problems: The exceptions are only
> catched if I debug with F5. Running without debugging neither in the
> release nor in the debug build the exceptions are catched. I also tried
> to catch the System::Runtime::InteropServices::SEHException and
> System::Exception but they aren't catched neither.
> But I have enabled the compiler option for exceptions (/EHsc) and
> catching exceptions within the unmanaged code works fine.
>
> Any ideas what can cause this strange behaviour? Could it be a problem
> that the exceptions are thrown/catched across dll boundaries?
>

Steve McLellan wrote:

> Have a look at SEHException - it allows you to retrieve info related to the
> original exception (see MSDN for
> System::Runtime::InteropServices::SEHException).
>
> What's unusual is that you were able to catch the std::exception at all. I
> don't know how this stands to change in the future; I'm writing production
> code so haven't used any of the 2005 beta releases.

> Also see this, and have a Google for information about exception handling in
> mixed C++.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcconBasicConceptsInUsingManagedExceptions.asp

Vasco Lohrenscheit wrote:
> //managed code:
> try
> {
> //the form loads unmanaged dlls out of which unmanaged exception
> //get thrown
> Application::Run(new Form1());
> } catch (std::exception& e)
> {
> //catching work in debud build, in release build a SEHException
> //gets thrown
> }
> But with the release build the same c++ exceptions are not catched but I
> get a SEHException from the .net framework. Any idea what can cause this
> Problem? I already checked build options and c++ exceptions are enabled
> in the release build too, so the problem has to lie somewhere else...
>

"Russell Hind" <no-one@no-where.com> wrote in message
news:OcGqa4kdEHA.3792@TK2MSFTNGP09.phx.gbl...
> Vasco Lohrenscheit wrote:
> > //managed code:
> > try
> > {
> > //the form loads unmanaged dlls out of which unmanaged exception
> > //get thrown
> > Application::Run(new Form1());
> > } catch (std::exception& e)
> > {
> > //catching work in debud build, in release build a SEHException
> > //gets thrown
> > }
> > But with the release build the same c++ exceptions are not catched but I
> > get a SEHException from the .net framework. Any idea what can cause this
> > Problem? I already checked build options and c++ exceptions are enabled
> > in the release build too, so the problem has to lie somewhere else...
> >
>
> I've read the other replies and just wondered: Does Application::Run
> have its own catch clause in? If so, I guess its a catch (SEHExecption)
> so won't that mean and std::exception will get matched to the
> SEHException clause in side Application::Run?
>
> This is how Borland VCL works, each time a message is processed, it is
> wrapped in a try/catch block that you can't over-ride.
>
> (Difference is that there, c++ (unmanaged) exceptions aren't caught and
> so do propergate back to the main function.
>

>>
>>I've read the other replies and just wondered: Does Application::Run
>>have its own catch clause in? If so, I guess its a catch (SEHExecption)
>>so won't that mean and std::exception will get matched to the
>>SEHException clause in side Application::Run?
>>
>>This is how Borland VCL works, each time a message is processed, it is
>>wrapped in a try/catch block that you can't over-ride.
>>
>>(Difference is that there, c++ (unmanaged) exceptions aren't caught and
>>so do propergate back to the main function.

>
> There may be something in this, except that if this were the case you'd be
> getting an automatic 'unhandled exception' dialog popping up, and this
> apparently isn't happening. Still ,in the absence of any more ideas it's
> something to look at.

> I was under the misguided impression that the exception handler was around
> the DLL call. You could try looking at
> System::AppDomain::CurrentDomain->UnhandledException and
> Application::ThreadException. You can attach exception handlers there for
> unhandled exceptions further up the stack.

Steve McLellan wrote:

> I was under the misguided impression that the exception handler was around
> the DLL call. You could try looking at
> System::AppDomain::CurrentDomain->UnhandledException and
> Application::ThreadException. You can attach exception handlers there for
> unhandled exceptions further up the stack.

Vasco Lohrenscheit wrote:
>
> In Application::ThreadException I get a SEHException. Is it possible to
> extract the original c++ exception from it?
> Or any other way to handle c++ exceptions globaly in managed code?
>

"Russell Hind" <no-one@no-where.com> wrote in message
news:u$w5VntdEHA.1764@TK2MSFTNGP10.phx.gbl...
> Vasco Lohrenscheit wrote:
> >
> > In Application::ThreadException I get a SEHException. Is it possible to
> > extract the original c++ exception from it?
> > Or any other way to handle c++ exceptions globaly in managed code?
> >
>
> I doubt it. This is the problem with mixed language environments
> (again, we have the same problem in C++Builder. Exceptions are normally
> pascal. The Run() routine catches pascal exceptions but not C++
> exceptions so you have to catch these everywhere yourself or just catch
> it in the WinMain and exit the app.
>
> If you could over-ride Application::Run (or a sub part of it) then maybe
> it could set up the try catch for SEH then call a 'ProcessMessage'
> method which you can over-ride and set up your own try catch for
> std::exception and then call inherited ProcessMessage method.
>
> But this would require a change to the CLR I guess.