All contents in the core.sys.windows.windows module in 2.061 are marked as nothrow.

nothrow means exceptions derived from the Exception class are not allowed to propagate. In other words now that the WNDPROC function pointer is expected to be nothrow you have to wrap any statements which might throw Exception objects in a try/catch block.

SEH[1] is implemented in D for x86 (x64 not yet, but maybe some day),
therefore exceptions can propagate, and they do as this sample will
show you if you compile it with 2.060:
https://github.com/AndrejMitrovic/dmd/blob/662db08ce9dd27d2c79d04ab4ccea9823f6142a1/test/win32/testthrow.d#L23

Are there problems with the SEH implementation which forces us to use nothrow on win32? If there are then this should be documented.

On 12/26/2012 2:12 PM, Andrej Mitrovic wrote:
> All contents in the core.sys.windows.windows module in 2.061 are
> marked as nothrow.
>
> nothrow means exceptions derived from the Exception class are not
> allowed to propagate. In other words now that the WNDPROC function
> pointer is expected to be nothrow you have to wrap any statements
> which might throw Exception objects in a try/catch block.
>
> SEH[1] is implemented in D for x86 (x64 not yet, but maybe some day),
> therefore exceptions can propagate, and they do as this sample will
> show you if you compile it with 2.060:
> https://github.com/AndrejMitrovic/dmd/blob/662db08ce9dd27d2c79d04ab4ccea9823f6142a1/test/win32/testthrow.d#L23
>
> Are there problems with the SEH implementation which forces us to use
> nothrow on win32? If there are then this should be documented.
>

The operating system calls WNDPROC directly. That means that you (the user) need to set up / tear down the D runtime yourself, much like what C main() does in druntime. Windows has no knowledge of D Exceptions, and it makes no sense to me to try to pass them on to Windows. WNDPROC should deal with them.

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:

extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
    int result;
    void exceptionHandler(Throwable e) { throw e; }

    try
    {
        Runtime.initialize(&exceptionHandler);
        result = myWinMain(hInstance, hPrevInstance, lpCmdLine, iCmdShow);
        Runtime.terminate(&exceptionHandler);
    }
    catch (Throwable o)
    {
        MessageBox(null, o.toString().toUTF16z, "Error", MB_OK |
MB_ICONEXCLAMATION);
        result = 0;
    }

    return result;
}

This is the top-level exception handler where exceptions from within a WNDPROC propagate to if they're not caught.

On 12/26/2012 2:47 PM, 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:

You're right. But the whole reason to declare functions as being of type WNDPROC is they are called by Windows. Windows knows nothing about D exceptions, and I think that it's courting disaster for a function to hand them off to Windows.

This applies to any attempt to throw D exceptions in code called by non-D code.

On 12/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
> Windows knows nothing about D exceptions

Then why does my code sample work?

If Windows really knows nothing about D exceptions why are we letting
Error and Throwable through, shouldn't we also catch those and then
call core.stdc.exit() or ExitProcess()?

On 12/26/2012 6:26 PM, Andrej Mitrovic wrote:
> On 12/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
>> Windows knows nothing about D exceptions
>
> Then why does my code sample work?

A lot of code can appear to work, but that doesn't mean it is correct and robust and will work on future versions of Windows. Code should not impute things into an ABI spec. The Windows ABI spec says nothing at all about accepting D exceptions, therefore none should be presented to it.


> If Windows really knows nothing about D exceptions why are we letting
> Error and Throwable through, shouldn't we also catch those and then
> call core.stdc.exit() or ExitProcess()?

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.

On Thursday, 27 December 2012 at 02:26:11 UTC, Andrej Mitrovic wrote:
> On 12/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
>> Windows knows nothing about D exceptions
>
> Then why does my code sample work?

Have a look at the "Remarks" section of the WNDPROC documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633573(v=vs.85).aspx

It looks like the behavior will vary greatly on 64-bit Windows OSes (for both 32-bit and 64-bit apps).

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 ?

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?

On 12/27/2012 12:50 AM, Vladimir Panteleev wrote:
> On Thursday, 27 December 2012 at 02:26:11 UTC, Andrej Mitrovic wrote:
>> On 12/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
>>> Windows knows nothing about D exceptions
>>
>> Then why does my code sample work?
>
> Have a look at the "Remarks" section of the WNDPROC documentation:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms633573(v=vs.85).aspx
>
> It looks like the behavior will vary greatly on 64-bit Windows OSes (for both
> 32-bit and 64-bit apps).

That pretty much confirms to me that you shouldn't generate SEH exceptions and send them to Windows unless you have studied the issue carefully. Just throwing D exceptions and assuming Windows will do the right thing, whatever that is, with them is a mistake.