On Thursday, 27 December 2012 at 18:16:35 UTC, Andrej Mitrovic wrote:
> 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.

So, if I got this right, doing this is not ideal:
extern( Windows ) nothrow LRESULT WndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) {
try {
...
} catch( Exception e ) { ... }
}

And should be changed to :
catch( Throwable t ) { ... }
?

Thanks,
Phil

On Dec 27, 2012, at 5:46 PM, Brad Roberts <braddr@puremagic.com> wrote:

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

This. Is there some reason we really need a different unwinding mechanism?

On 27/12/2012 18:16, Andrej Mitrovic wrote:
> 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.

The WNDPROC defined by SDWF catches exceptions and displays a message box that gives the exception's toString and offers the user the choice of trying to continue or aborting the program.

Stewart.

On 12/28/2012 5:29 AM, Phil Lavoie wrote:
> So, if I got this right, doing this is not ideal:
> extern( Windows ) nothrow LRESULT WndProc( HWND hwnd, UINT message, WPARAM
> wParam, LPARAM lParam ) {
> try {
> ...
> } catch( Exception e ) { ... }
> }
>
> And should be changed to :
> catch( Throwable t ) { ... }
> ?

Yes.