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

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

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

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

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.

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