On Thursday, 27 December 2012 at 09:29:08 UTC, Walter Bright wrote:
> On 12/27/2012 12:52 AM, deadalnix wrote:
>> On Thursday, 27 December 2012 at 01:39:11 UTC, Walter Bright wrote:
>>> This applies to any attempt to throw D exceptions in code called by non-D code.
>>
>> BTW, Why D isn't using the system defined exception ABI if one exists (like on
>> windows) ? Is-it intentional, or lack of documentation/manpower ?
>
> D does use Windows SEH for win32, but not for win64. But still, you gotta ask yourself, what do expect Windows to do with a D exception?

I think it has several advantages to use the same ABI :
 - Exception cal bubble from D to C++ then back to D to be handled. C++ will run RAII code properly, even if it can't do anything useful with the D exception. This is common when using function pointer or virtual methods.
 - The same thing goes the other way around : C++ Exception can go throw D code, unwinding stack cleanly. Even if D program cannot do anything really ith the C++ exception, it can at least fail safely and with a stack trace.

In many cases, exception are more about exit cleanly than actually catch them and recover. For such a case, common ABI is useful.

On 12/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
> Take a look at druntime\src\rt\dmain2.d. It catches all Throwable's and
> swallows
> them - it does not expect the C runtime to handle D exceptions. This is why
> Throwable is still catchable.

So then `nothrow` on the headers isn't enough since it only guarantees we're catching Exception types and letting Nothrow types through to Windows functions. It sounds to me like we need even stricter enforcement on the headers which the language doesn't provide right now (in hindsight maybe 'nothrow' should have been called 'noexcept').

For example people have problems throwing on x64 in C++ inside a
WNDPROC: http://stackoverflow.com/questions/2631452/64bit-exceptions-in-wndproc-silently-fail

I wonder if D has the same problem if an Error or Throwable escapes a WNDPROC?

Am Thu, 27 Dec 2012 16:32:41 +0100
schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> On 12/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
> > Take a look at druntime\src\rt\dmain2.d. It catches all Throwable's
> > and swallows
> > them - it does not expect the C runtime to handle D exceptions.
> > This is why Throwable is still catchable.
> 
> So then `nothrow` on the headers isn't enough since it only guarantees we're catching Exception types and letting Nothrow types through to Windows functions. It sounds to me like we need even stricter enforcement on the headers

That would probably be useful but I fear it's too late / would make the language too complicated.

There's a similar problem in GDC: http://gdcproject.org/bugzilla/show_bug.cgi?id=10

Right now we can't really use nothrow for optimization / we can't simply map it to the gcc nothrow attribute. To the GCC backend it doesn't matter if we throw an exception or an error, __attribute__(nothrow) means the function won't throw anything.

We could of course do some advanced conservative analysis on the function (does it call other functions, ...) but that could be done on all functions, nothrow doesn't help there.

On 12/27/2012 7:32 AM, Andrej Mitrovic wrote:
> So then `nothrow` on the headers isn't enough since it only guarantees
> we're catching Exception types and letting Nothrow types through to
> Windows functions. It sounds to me like we need even stricter
> enforcement on the headers which the language doesn't provide right
> now (in hindsight maybe 'nothrow' should have been called 'noexcept').
>
> For example people have problems throwing on x64 in C++ inside a
> WNDPROC: http://stackoverflow.com/questions/2631452/64bit-exceptions-in-wndproc-silently-fail
>
> I wonder if D has the same problem if an Error or Throwable escapes a WNDPROC?

Probably.

Is it an issue as you describe? Yes. Is it a big enough issue to merit a language change? I doubt it.

On 12/27/2012 1:52 AM, deadalnix wrote:
> On Thursday, 27 December 2012 at 09:29:08 UTC, Walter Bright wrote:
>> D does use Windows SEH for win32, but not for win64. But still, you gotta ask
>> yourself, what do expect Windows to do with a D exception?
>
> I think it has several advantages to use the same ABI :
>   - Exception cal bubble from D to C++ then back to D to be handled. C++ will
> run RAII code properly, even if it can't do anything useful with the D
> exception. This is common when using function pointer or virtual methods.
>   - The same thing goes the other way around : C++ Exception can go throw D
> code, unwinding stack cleanly. Even if D program cannot do anything really ith
> the C++ exception, it can at least fail safely and with a stack trace.
>
> In many cases, exception are more about exit cleanly than actually catch them
> and recover. For such a case, common ABI is useful.

There is some merit to your argument, and that was the original idea behind building D exceptions out of Win32 SEH. I did the same for the Digital Mars C++ compiler.

But in practice, and I include a decade with DMC++, I've just never seen a useful application of it.

On 12/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
> Is it an issue as you describe? Yes. Is it a big enough issue to merit a language change? I doubt it.

Ok, but we should at least document it. Currently we only have a small remark in the docs saying exceptions in D are not compatible with C++ exceptions, but we should clarify and maybe add how to work around this, whether to catch Throwable, and what to do when its caught.

On 26/12/2012 22:47, Andrej Mitrovic wrote:
> On 12/26/12, Walter Bright <newshound2@digitalmars.com> wrote:
>> The operating system calls WNDPROC directly. That means that you (the user)
>> need to set up / tear down the D runtime yourself
>
> But we already do this in WinMain, which is called first:
<snip>

But on top of what Walter has said:

- Is it even guaranteed that the WNDPROC will be called only in the program's own call stack?

- Just looking at how SendMessage works across threads, can we rely on it to properly notify the calling thread that the message has been processed if the WNDPROC throws?

- Chances are you'll want to avoid just letting exceptions abort the entire program.

Stewart.

On 12/27/2012 10:16 AM, Andrej Mitrovic wrote:
> Ok, but we should at least document it. Currently we only have a small
> remark in the docs saying exceptions in D are not compatible with C++
> exceptions, but we should clarify and maybe add how to work around
> this, whether to catch Throwable, and what to do when its caught.


Yes.

On Thu, 27 Dec 2012, Walter Bright wrote:

> On 12/27/2012 1:52 AM, deadalnix wrote:
> > On Thursday, 27 December 2012 at 09:29:08 UTC, Walter Bright wrote:
> > > D does use Windows SEH for win32, but not for win64. But still, you gotta
> > > ask
> > > yourself, what do expect Windows to do with a D exception?
> > 
> > I think it has several advantages to use the same ABI :
> >   - Exception cal bubble from D to C++ then back to D to be handled. C++
> > will
> > run RAII code properly, even if it can't do anything useful with the D
> > exception. This is common when using function pointer or virtual methods.
> >   - The same thing goes the other way around : C++ Exception can go throw D
> > code, unwinding stack cleanly. Even if D program cannot do anything really
> > ith
> > the C++ exception, it can at least fail safely and with a stack trace.
> > 
> > In many cases, exception are more about exit cleanly than actually catch
> > them
> > and recover. For such a case, common ABI is useful.
> 
> There is some merit to your argument, and that was the original idea behind building D exceptions out of Win32 SEH. I did the same for the Digital Mars C++ compiler.
> 
> But in practice, and I include a decade with DMC++, I've just never seen a useful application of it.

It doesn't matter if you can see the utility in it or not.  What matters is some combination of user expectations and general usability, both of which are fairly subjective.  Additionally, for most of that decade, mixing languages was fairly rare.  These days it's becoming increasingly common.  Presenting c++ libraries with c wrappers is much more common now. Using call backs and registration hooks for plugins and other extensibility mechanisms is WAY more common now than it was 10 years ago. In short, the landscape has and continues to change, so past history is a poor measuring stick for future code bases.

IMHO, having the unwinders NOT be common and uniform in behavior is a major usage problem.  It might not be important enough to hit the top of the todo list right now, but at some point it's going to be.  Either way, not being interoperable is a bug in my mind (and I include all the platform here, not just windows) and will need to be addressed.  It's roughly in the same category as supporting shared libraries.  They're not important at small scale, but at large scale they start to become critical.  If I can't rely on proper unwinding, there's going to be problems.

I'm not familiar with the windows side, but on the posix side, the c++ world developed a fairly sane, multi-language, unwinding system.  There's little reason NOT to use it, other than that it takes a little time to understand and hook into it, and going off on your own path is potentially simpler.

My 2 cents,
Brad

On Thursday, 27 December 2012 at 18:04:45 UTC, Walter Bright wrote:
> There is some merit to your argument, and that was the original idea behind building D exceptions out of Win32 SEH. I did the same for the Digital Mars C++ compiler.
>
> But in practice, and I include a decade with DMC++, I've just never seen a useful application of it.

I don't really know how things are on windows, but I found myself wish it worked on linux or OSX more than once.