• Niall Douglas (26/26) Jan 12 2003 Originally posted to websalesx1@digitalmars.com but was told to post her...
• Walter (10/32) Jan 12 2003 Thanks!
• Niall Douglas (30/44) Jan 12 2003 No problems. However, if I personally were designing a new language base...
• Walter (26/52) Jan 23 2003 I had the same problem. Self-funding my whacky ideas and creating D was ...

Niall Douglas <Niall_member pathlink.com> writes:

Originally posted to websalesx1 digitalmars.com but was told to post here
instead. I'll check back for replies tomorrow.

--- cut ---
Just wanted to say that you seem to have done a much better job on it than
Sun did on Java. I look forward to giving it a whirl when it's more
mature, though I must admit I find the lack of multiple inheritance
worrying (I very very occasionally use it when C++'s OO limitations get in
the way, though I totally accept your points about its complexity of
implementation).

However, I couldn't find anything in your docs about how you intend 
to implement the exception handling semantics. One of my biggest 
bugbears with C++ is its inability to handle an exception being 
thrown during the unwind of the stack due to another exception being
thrown (and thus make it impossible for sanity checks during any
destruction - hard to do when a destructor may construct some temporary
objects :( ). I have even emailed members of the ISO C++ committee about
this and never got a satisfactory explanation as to why this was done. I
personally feel they didn't think about it enough :(

Anyway, I was wondering how D intends to do this, or if it is? I 
proposed making the object stack a C++ object which can be cloned so that
multiple unwinds may happen simultaneously without any loss of information
or erroneous activity - in fact, this could be added to C++ and would
break perhaps 0.01% of existing code - still, no one seemed to take me
seriously (apparently my C++ coding style is wrong) :(

Cheers,
Niall Douglas

"Walter" <walter digitalmars.com> writes:

"Niall Douglas" <Niall_member pathlink.com> wrote in message
news:avrrgc$1539$1 digitaldaemon.com...
 Just wanted to say that you seem to have done a much better job on it than
 Sun did on Java.

Thanks!

 I look forward to giving it a whirl when it's more
 mature, though I must admit I find the lack of multiple inheritance
 worrying (I very very occasionally use it when C++'s OO limitations get in
 the way, though I totally accept your points about its complexity of
 implementation).

I've seen MI used a lot with COM, and D interfaces map right onto COM. MI
works with interfaces, so this just works out fine.

 However, I couldn't find anything in your docs about how you intend
 to implement the exception handling semantics. One of my biggest
 bugbears with C++ is its inability to handle an exception being
 thrown during the unwind of the stack due to another exception being
 thrown (and thus make it impossible for sanity checks during any
 destruction - hard to do when a destructor may construct some temporary
 objects :( ). I have even emailed members of the ISO C++ committee about
 this and never got a satisfactory explanation as to why this was done. I
 personally feel they didn't think about it enough :(

 Anyway, I was wondering how D intends to do this, or if it is? I
 proposed making the object stack a C++ object which can be cloned so that
 multiple unwinds may happen simultaneously without any loss of information
 or erroneous activity - in fact, this could be added to C++ and would
 break perhaps 0.01% of existing code - still, no one seemed to take me
 seriously (apparently my C++ coding style is wrong) :(

It's a great question. D's win32 implementation relies on the Win32
structured exception handling mechanism. Currently, if another exception is
thrown while unwinding, the code aborts the program. You can still use
asserts and contracts during an unwind, it's just that if they fail, the
program will exit.

Niall Douglas <Niall_member pathlink.com> writes:

 Just wanted to say that you seem to have done a much better job on it than
 Sun did on Java.

Thanks!

No problems. However, if I personally were designing a new language based on C,
I'd be far more radical than you have been :) - for a start, although I'm
proficient in OO, I've never felt it was right to design programs around it.
Furthermore, purely imperative languages seem anachronistic to me for anything
higher level than C.

I'd personally go for a data processor-orientated functional/imperative hybrid
with C syntax. Of course, since the world is OO and imperative mad, most people
think I've got a screw loose (and turn down my funding wherever I go with my
whacky ideas! :( ). Still, someday ...

 Anyway, I was wondering how D intends to do this, or if it is? I
 proposed making the object stack a C++ object which can be cloned so that
 multiple unwinds may happen simultaneously without any loss of information
 or erroneous activity - in fact, this could be added to C++ and would
 break perhaps 0.01% of existing code - still, no one seemed to take me
 seriously (apparently my C++ coding style is wrong) :(

It's a great question. D's win32 implementation relies on the Win32
structured exception handling mechanism. Currently, if another exception is
thrown while unwinding, the code aborts the program. You can still use
asserts and contracts during an unwind, it's just that if they fail, the
program will exit.

Hmm. This (and I really hope you agree) breaks the real-world usefulness of your
language. My view, not shared by some of the ISO C++ committee, is that the
whole point of exceptions is for code to notify other code of a problem
irrespective of time and location. I for one feel the often common practice on
Windows and especially Unix in C++ of printing a message to stderr and taking a
default (often to do nothing) is just plain bad coding. Needless to say, saying
this loudly gets some people awfully angry :(

I believe it's possible to install your own custom win32 SEH handlers - there
was a MSDN article by Matt Pietrek about just this I remember - it's all about
setting the thread local information block register I think, so you could
probably just implement it manually. If in handling the exception you wrapped
the stack unwind code for that stack frame in its own __try...__catch you could
build a LIFO thread-local stack of thrown exceptions and then filter out the
relevent caught exceptions for each catch handler running up the stack till the
stack was empty. In fact, that thread local information block may even be
completely up to you to define, so you could store the exception stack in there.

Some day I'll get round to hacking GCC to make it do what I want, but I vaguely
remember it's more complicated there in order to keep it compatible with
existing code. Anyway, back to coding ...

Cheers,
Niall

"Walter" <walter digitalmars.com> writes:

"Niall Douglas" <Niall_member pathlink.com> wrote in message
news:avsk44$df6$1 digitaldaemon.com...
 and turn down my funding wherever I go with my
 whacky ideas! :( ). Still, someday ...

I had the same problem. Self-funding my whacky ideas and creating D was the
only solution <g>.

It's a great question. D's win32 implementation relies on the Win32
structured exception handling mechanism. Currently, if another exception


is
thrown while unwinding, the code aborts the program. You can still use
asserts and contracts during an unwind, it's just that if they fail, the
program will exit.

 Hmm. This (and I really hope you agree) breaks the real-world usefulness

of your
 language. My view, not shared by some of the ISO C++ committee, is that

the
 whole point of exceptions is for code to notify other code of a problem
 irrespective of time and location. I for one feel the often common

practice on
 Windows and especially Unix in C++ of printing a message to stderr and

taking a
 default (often to do nothing) is just plain bad coding. Needless to say,

saying
 this loudly gets some people awfully angry :(

My view on exceptions is they should be used for error reporting, and that
printing a message and exiting is at least reasonable behavior as opposed to
crashing randomly, which is what pre-exception handling code did all too
often.


 I believe it's possible to install your own custom win32 SEH handlers -

there
 was a MSDN article by Matt Pietrek about just this I remember - it's all

about
 setting the thread local information block register I think, so you could
 probably just implement it manually. If in handling the exception you

wrapped
 the stack unwind code for that stack frame in its own __try...__catch you

could
 build a LIFO thread-local stack of thrown exceptions and then filter out

the
 relevent caught exceptions for each catch handler running up the stack

till the
 stack was empty. In fact, that thread local information block may even be
 completely up to you to define, so you could store the exception stack in

there.

It's probably possible to do this. But it's beyond the scope of my thinking
at the moment.

 Some day I'll get round to hacking GCC to make it do what I want, but I

vaguely
 remember it's more complicated there in order to keep it compatible with
 existing code. Anyway, back to coding ...

The way G++ does exceptions is a mystery I wasn't able to solve without
spending a great deal of time reading the G++ source code.