www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I WANT

reply Georg Wrede <georg.wrede nospam.org> writes:
   ?

Well, I've not wanted stuff for some time, so now it's my turn!

I want:

  - The discussion about program termination or not, to end.

  - Two throwables: one catchable, one not catchable.
    No more, and no less than these two. Let library
    programmers inherit from these two.

  - Catch clauses to be able to examine and rethrow,
    or throw something else, if they want.

  - Contract checking to be on or off, but absolutely no
    grey areas in between.

  - Those who don't want CP, to instead use exceptions or
    whatever else. And let CP live in peace.

And if anybody opposes this post, I'll consider him Sub Simian, I'll 
laugh at him secretly, and then I'm gonna tell on you to Walter and Mom.

---------------

Seriously, though, I really do want these things.
And I have seen enough discussion about them already,
thank you very much.
Apr 13 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:425CE5DC.2030709 nospam.org...

   ?

 Well, I've not wanted stuff for some time, so now it's my turn!

 I want:

  - The discussion about program termination or not, to end.


Already ended. At least I think so.


  - Two throwables: one catchable, one not catchable.
    No more, and no less than these two. Let library
    programmers inherit from these two.


I take it you mean quenchable and not quenchable? Specifically, the not
quenchable type - currently called Errors - can 
be caught but are rethrown at the end of the catch scope if they, or another
unquenchable type is not rethrown.

If that's what you mean, I can live with the binary taxonomy. :-)


  - Catch clauses to be able to examine and rethrow,
    or throw something else, if they want.


Does this include


  - Contract checking to be on or off, but absolutely no
    grey areas in between.


Agreed. I think it was you that observed that we're going to have CP and no-CP
versions of all libraries, including 
Phobos. So more than two's going to hurt a lot.


  - Those who don't want CP, to instead use exceptions or
    whatever else. And let CP live in peace.

 And if anybody opposes this post, I'll consider him Sub Simian, I'll laugh at
him secretly, and then I'm gonna tell on 
 you to Walter and Mom.

 ---------------

 Seriously, though, I really do want these things.
 And I have seen enough discussion about them already,
 thank you very much.


Agreed.
Apr 13 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:

 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:425CE5DC.2030709 nospam.org...
 

 ?
 
 Well, I've not wanted stuff for some time, so now it's my turn!
 
 I want:
 
 - The discussion about program termination or not, to end.


 
 
 Already ended. At least I think so.
 
 

 - Two throwables: one catchable, one not catchable. No more, and no
 less than these two. Let library programmers inherit from these
 two.


 
 
 I take it you mean quenchable and not quenchable? Specifically, the
 not quenchable type - currently called Errors - can be caught but are
 rethrown at the end of the catch scope if they, or another
 unquenchable type is not rethrown.
 
 If that's what you mean, I can live with the binary taxonomy. :-)


That's what I mean. Thanks for the clarification. Good!


 Does this include


I'm not /that/ smart. So I didn't understand the line above.

Anyhow, CP and throwing stuff are orthogonal, IMHO.


 - Contract checking to be on or off, but absolutely no grey areas
 in between.


 
 
 Agreed. I think it was you that observed that we're going to have CP
 and no-CP versions of all libraries, including Phobos. So more than
 two's going to hurt a lot.


It would hurt. It's also a matter of principle. CP is not to be 
excercised half-heartedly.


 - Those who don't want CP, to instead use exceptions or whatever
 else. And let CP live in peace.
 
 And if anybody opposes this post, I'll consider him Sub Simian,
 I'll laugh at him secretly, and then I'm gonna tell on you to
 Walter and Mom.
 
 ---------------
 
 Seriously, though, I really do want these things. And I have seen
 enough discussion about them already, thank you very much.


 
 
 Agreed.
Apr 13 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d3ipn0$1ai1$2 digitaldaemon.com>, Matthew says...

I take it you mean quenchable and not quenchable? Specifically, the not
quenchable type - currently called Errors - can 
be caught but are rethrown at the end of the catch scope if they, or another
unquenchable type is not rethrown.


FWIW, the language implementation for Error that most makes sense to me is to
declare it as an auto class and put terminate() in its dtor.  Since exceptions
are a rather odd case in that they don't truly leave scope until execution
leaves a catch block either normally or by throwing something else, this would
be a pretty straightforward way to implement this feature.  The only sticking
point would be if this error were chained via the 'next' reference--the code
would have to be intelligent enough to notice this and defer destruction.
Unless, of course, this were deemed illegal in which case it could be destroyed
normally at that time.


Sean
Apr 13 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:d3jg73$1va3$1 digitaldaemon.com...

 In article <d3ipn0$1ai1$2 digitaldaemon.com>, Matthew says...

I take it you mean quenchable and not quenchable? Specifically, 
the not quenchable type - currently called Errors - can
be caught but are rethrown at the end of the catch scope if they, 
or another unquenchable type is not rethrown.


 FWIW, the language implementation for Error that most makes sense 
 to me is to
 declare it as an auto class and put terminate() in its dtor. 
 Since exceptions
 are a rather odd case in that they don't truly leave scope until 
 execution
 leaves a catch block either normally or by throwing something 
 else, this would
 be a pretty straightforward way to implement this feature.


The issue there, I guess, is that there would be no option for 
quenching it. Also, I think they need to be catchable, because in 
most cases an instant termination is not desirable.


  The only sticking
 point would be if this error were chained via the 'next' 
 reference--the code
 would have to be intelligent enough to notice this and defer 
 destruction.
 Unless, of course, this were deemed illegal in which case it could 
 be destroyed
 normally at that time.


Perhaps we could employ a similar mechanism as I've used in the 
STLSoft unrecoverable (and its derived class contract_violation), 
whereby they ref-count a heap allocated long.
Apr 13 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425CE5DC.2030709 nospam.org...

   ?

 Well, I've not wanted stuff for some time, so now it's my turn!

 I want:

  - The discussion about program termination or not, to end.


So you want to terminate the program termination thread. Can't I catch that? 
just kidding. I think everyone understands the arguments on both sides after 
all those posts.


  - Two throwables: one catchable, one not catchable.
    No more, and no less than these two. Let library
    programmers inherit from these two.

  - Catch clauses to be able to examine and rethrow,
    or throw something else, if they want.

  - Contract checking to be on or off, but absolutely no
    grey areas in between.

  - Those who don't want CP, to instead use exceptions or
    whatever else. And let CP live in peace.

 And if anybody opposes this post, I'll consider him Sub Simian, I'll laugh 
 at him secretly, and then I'm gonna tell on you to Walter and Mom.

 ---------------

 Seriously, though, I really do want these things.
 And I have seen enough discussion about them already,
 thank you very much.


I sympathize. The general topic unfortunately won't end until phobos and/or 
the compiler changes (and even then it probably won't end) so it will have 
to come up again. That is one thing we all can agree on :-). The devil is in 
the details but D will be better for it.
Apr 13 2005