www.digitalmars.com         C & C++   DMDScript  

D - About D's exception handling

reply 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
Jan 12 2003
parent reply "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.
Jan 12 2003
parent reply 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
Jan 12 2003
parent "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


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.


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

 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

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

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

 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 -

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

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

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

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

 relevent caught exceptions for each catch handler running up the stack

 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

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

 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.
Jan 23 2003