September 28, 2012
On 9/27/2012 11:01 PM, Jacob Carlborg wrote:
> On 2012-09-27 21:51, Walter Bright wrote:
> 
>> Well, I did. The EH mechanism in dmd Win64 is the same as that used for dmd Linux, OSX and FreeBSD, 32 and 64.
> 
> What does that practically mean from the users point of view?

It's another interoperability problem.  It means that when mixing c++/d that stackframe unwinding during exception handling doesn't work as expected.  It'll be one more thing that eventually needs to be fixed.

September 28, 2012
On 9/28/12, Brad Roberts <braddr@puremagic.com> wrote:
> It's another interoperability problem.  It means that when mixing c++/d that
> stackframe unwinding during exception
> handling doesn't work as expected.  It'll be one more thing that eventually
> needs to be fixed.

I thought the whole COFF work was entirely about interoperability
(well, that and 64bit). Oh well..
September 28, 2012
On Fri, 28 Sep 2012, Andrej Mitrovic wrote:

> On 9/28/12, Brad Roberts <braddr@puremagic.com> wrote:
> > It's another interoperability problem.  It means that when mixing c++/d that
> > stackframe unwinding during exception
> > handling doesn't work as expected.  It'll be one more thing that eventually
> > needs to be fixed.
> 
> I thought the whole COFF work was entirely about interoperability
> (well, that and 64bit). Oh well..

Interoperability isn't a single attribute.  It's an accumulation of tons of attributes.  Much like .so/.dll support.  So, 2 steps forward, but 20 left (obviously making up those numbers).
September 28, 2012
On 9/27/2012 11:01 PM, Jacob Carlborg wrote:
> On 2012-09-27 21:51, Walter Bright wrote:
>
>> Well, I did. The EH mechanism in dmd Win64 is the same as that used for
>> dmd Linux, OSX and FreeBSD, 32 and 64.
>
> What does that practically mean from the users point of view?

It means D cannot throw or catch VC exceptions, and VC code cannot throw or catch D exceptions.

Pretty much just like on Linux/OSX/FreeBSD, which doesn't seem to be a problem.


September 28, 2012
On 9/28/2012 10:43 AM, Andrej Mitrovic wrote:
> I thought the whole COFF work was entirely about interoperability
> (well, that and 64bit). Oh well..


COFF is just a file format, nothing more. It is not an ABI specification.

September 28, 2012
On Fri, 28 Sep 2012, Walter Bright wrote:

> On 9/27/2012 11:01 PM, Jacob Carlborg wrote:
> > On 2012-09-27 21:51, Walter Bright wrote:
> > 
> > > Well, I did. The EH mechanism in dmd Win64 is the same as that used for dmd Linux, OSX and FreeBSD, 32 and 64.
> > 
> > What does that practically mean from the users point of view?
> 
> It means D cannot throw or catch VC exceptions, and VC code cannot throw or catch D exceptions.
> 
> Pretty much just like on Linux/OSX/FreeBSD, which doesn't seem to be a problem.

It's more than just catching.  That's a relatively minor issue.  The bigger one is stack unwinding and related cleanups.  Consider: c++ function with local variables that have dtors that calls a D function that throws.  Those c++ locals will never have their dtors called.

It's not a huge problem, but the sum of the problems add up to pain and will need to be fixed at some point.  The lack of pain today is that it's barely feasible to mix languages where more than one has any exception handling right now.  Something of a catch-22 of issues, imho.
September 29, 2012
On 9/28/2012 12:39 PM, Brad Roberts wrote:
> It's more than just catching.  That's a relatively minor issue.  The
> bigger one is stack unwinding and related cleanups.  Consider: c++
> function with local variables that have dtors that calls a D function that
> throws.  Those c++ locals will never have their dtors called.
>
> It's not a huge problem, but the sum of the problems add up to pain and
> will need to be fixed at some point.  The lack of pain today is that it's
> barely feasible to mix languages where more than one has any exception
> handling right now.  Something of a catch-22 of issues, imho.


True, but I would never write code that tried to throw an exception across language boundaries, anyway. It's just asking for trouble.


September 29, 2012
On Fri, 28 Sep 2012, Walter Bright wrote:

> On 9/28/2012 12:39 PM, Brad Roberts wrote:
> > It's more than just catching.  That's a relatively minor issue.  The bigger one is stack unwinding and related cleanups.  Consider: c++ function with local variables that have dtors that calls a D function that throws.  Those c++ locals will never have their dtors called.
> > 
> > It's not a huge problem, but the sum of the problems add up to pain and will need to be fixed at some point.  The lack of pain today is that it's barely feasible to mix languages where more than one has any exception handling right now.  Something of a catch-22 of issues, imho.
> 
> 
> True, but I would never write code that tried to throw an exception across language boundaries, anyway. It's just asking for trouble.

And that's fine for your code, but if you want D and DMD to be a system that people use for larger systems, then cutting down the sheer number of things that don't work when pushed is kinda important.
September 29, 2012
On Fri, 28 Sep 2012 18:20:12 -0700
Brad Roberts <braddr@slice-2.puremagic.com> wrote:

> On Fri, 28 Sep 2012, Walter Bright wrote:
> 
> > True, but I would never write code that tried to throw an exception across language boundaries, anyway. It's just asking for trouble.
> 
> And that's fine for your code, but if you want D and DMD to be a system that people use for larger systems, then cutting down the sheer number of things that don't work when pushed is kinda important.


Especially since one of D's big selling points is linking with C/C++ code.

If such linking causes trouble with exceptions then people are
going to think twice about trying it (which reduces a major inroad for
D), or discover by surprise that it doesn't work and get
frustrated/annoyed.

September 29, 2012
On Saturday, September 29, 2012 06:41:01 Nick Sabalausky wrote:
> On Fri, 28 Sep 2012 18:20:12 -0700
> 
> Brad Roberts <braddr@slice-2.puremagic.com> wrote:
> > On Fri, 28 Sep 2012, Walter Bright wrote:
> > > True, but I would never write code that tried to throw an exception across language boundaries, anyway. It's just asking for trouble.
> > 
> > And that's fine for your code, but if you want D and DMD to be a system that people use for larger systems, then cutting down the sheer number of things that don't work when pushed is kinda important.
> 
> Especially since one of D's big selling points is linking with C/C++ code.
> 
> If such linking causes trouble with exceptions then people are
> going to think twice about trying it (which reduces a major inroad for
> D), or discover by surprise that it doesn't work and get
> frustrated/annoyed.

It's a problem that I've run into at work between C++ and the C# interop layer for one of our programs. A .NET bug with regards to C++ exceptions being thrown from C++ code resulted in destructors not being run when they were caught in the managed C++ code (and that's the _managed C++_, not even C#). Mutexes weren't being unlocked as a result, and it wasn't pretty. Making sure that exceptions didn't escape the normal C++ code would have fixed it, but we shouldn't have had to do that. It may be a relatively rare issue, but it _is_ something that can cause bugs.

That being said, it probably _is_ better practice to make sure that you catch all exceptions at language barriers, even if they both use exceptions, but still, you know that some people are going to try and have exceptions cross those barriers, and if it doesn't work, they'll have bugs (and bugs which could be very hard to find depending). So, in the long run at least, it would be very desirable to have this compatability issue resolved.

- Jonathan M Davis