?

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.

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

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

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

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

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