• Walter Bright (1/1) Sep 30 2008 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_...
• Janderson (6/8) Oct 01 2008 Perhaps now constructors can enforce no-throw. Functions that have
• dsimcha (10/18) Oct 01 2008 Please, please, please, please, *please* no!!! Anything that is in any ...
• Andrei Alexandrescu (4/21) Oct 01 2008 I agree. Bondage and discipline, heh :o). I'm actually surprised at the
• Janderson (6/37) Oct 01 2008 If an exception fires during the construction of an object and you don't...
• Andrei Alexandrescu (5/42) Oct 02 2008 But C++ solved this by making it impossible to obtain a
• Janderson (9/55) Oct 02 2008 That's a good point, I guess the issue I've had in the past is with
• Andrei Alexandrescu (7/64) Oct 02 2008 Either you encapsulate the resource itself in its own object, or you use...
• Janderson (8/77) Oct 02 2008 Maybe there should be some sort of way to detect handles that are not
• Fawzi Mohamed (9/82) Oct 02 2008 I have the impression this whole argument comes from the need to
• Janderson (4/62) Oct 02 2008 Maybe there should be some sort of way to detect handles that are not
• Sean Kelly (5/11) Oct 02 2008 Yup, which is why it's possible to wrap the class member initializer

Walter Bright <newshound1 digitalmars.com> writes:

http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_programming_language/

Janderson <ask me.com> writes:

Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_p
ogramming_language/ 
 

Perhaps now constructors can enforce no-throw.  Functions that have 
throw would have to be handled in that constructor.  Of course we could 
always do this manually, but it might be worth considering making on by 
default for constructors.

-Joel

dsimcha <dsimcha yahoo.com> writes:

== Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:


http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_programming_language/

 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we could
 always do this manually, but it might be worth considering making on by
 default for constructors.
 -Joel

Please, please, please, please, *please* no!!!  Anything that is in any way
similar to checked exception Hell in Java does not belong in D.  Nothrow is a
great feature precisely because, by being a contract that is only enforced when
the programmer explicitly asks for it to be, it can be simply ignored in places
where one doesn't want to use it.  Making nothrow the default in constructors
really smacks of Java-style bondage and discipline, and a major reason why I
use D
is to avoid such things.  If nothrow is the default *anywhere*, it will lead to
aggravation and error swallowing similar to Java's checked exceptions.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_programming_language/
 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we could
 always do this manually, but it might be worth considering making on by
 default for constructors.
 -Joel

 
 Please, please, please, please, *please* no!!!  Anything that is in any way
 similar to checked exception Hell in Java does not belong in D.  Nothrow is a
 great feature precisely because, by being a contract that is only enforced when
 the programmer explicitly asks for it to be, it can be simply ignored in places
 where one doesn't want to use it.  Making nothrow the default in constructors
 really smacks of Java-style bondage and discipline, and a major reason why I
use D
 is to avoid such things.  If nothrow is the default *anywhere*, it will lead to
 aggravation and error swallowing similar to Java's checked exceptions.

I agree. Bondage and discipline, heh :o). I'm actually surprised at the 
desire of making most constructors nothrow. Why?

Andrei

Janderson <ask me.com> writes:

Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_p
ogramming_language/ 

 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we could
 always do this manually, but it might be worth considering making on by
 default for constructors.
 -Joel

 Please, please, please, please, *please* no!!!  Anything that is in 
 any way
 similar to checked exception Hell in Java does not belong in D.  
 Nothrow is a
 great feature precisely because, by being a contract that is only 
 enforced when
 the programmer explicitly asks for it to be, it can be simply ignored 
 in places
 where one doesn't want to use it.  Making nothrow the default in 
 constructors
 really smacks of Java-style bondage and discipline, and a major reason 
 why I use D
 is to avoid such things.  If nothrow is the default *anywhere*, it 
 will lead to
 aggravation and error swallowing similar to Java's checked exceptions.

 
 I agree. Bondage and discipline, heh :o). I'm actually surprised at the 
 desire of making most constructors nothrow. Why?
 
 Andrei

If an exception fires during the construction of an object and you don't 
handle it your left with a partially formed object.  It becomes 
difficult to then make that object an invariant.  This is particularly 
bad when it occurs in the base classes constructor.

-Joel

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Janderson wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_p
ogramming_language/ 

 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we could
 always do this manually, but it might be worth considering making on by
 default for constructors.
 -Joel

 Please, please, please, please, *please* no!!!  Anything that is in 
 any way
 similar to checked exception Hell in Java does not belong in D.  
 Nothrow is a
 great feature precisely because, by being a contract that is only 
 enforced when
 the programmer explicitly asks for it to be, it can be simply ignored 
 in places
 where one doesn't want to use it.  Making nothrow the default in 
 constructors
 really smacks of Java-style bondage and discipline, and a major 
 reason why I use D
 is to avoid such things.  If nothrow is the default *anywhere*, it 
 will lead to
 aggravation and error swallowing similar to Java's checked exceptions.

 I agree. Bondage and discipline, heh :o). I'm actually surprised at 
 the desire of making most constructors nothrow. Why?

 Andrei

 
 If an exception fires during the construction of an object and you don't 
 handle it your left with a partially formed object.  It becomes 
 difficult to then make that object an invariant.  This is particularly 
 bad when it occurs in the base classes constructor.

But C++ solved this by making it impossible to obtain a 
partially-constructed object. If the constructor throws, there's never 
an object to talk about.

Andrei

Janderson <ask me.com> writes:

Andrei Alexandrescu wrote:
 Janderson wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_p
ogramming_language/ 

 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we 
 could
 always do this manually, but it might be worth considering making 
 on by
 default for constructors.
 -Joel

 Please, please, please, please, *please* no!!!  Anything that is in 
 any way
 similar to checked exception Hell in Java does not belong in D.  
 Nothrow is a
 great feature precisely because, by being a contract that is only 
 enforced when
 the programmer explicitly asks for it to be, it can be simply 
 ignored in places
 where one doesn't want to use it.  Making nothrow the default in 
 constructors
 really smacks of Java-style bondage and discipline, and a major 
 reason why I use D
 is to avoid such things.  If nothrow is the default *anywhere*, it 
 will lead to
 aggravation and error swallowing similar to Java's checked exceptions.

 I agree. Bondage and discipline, heh :o). I'm actually surprised at 
 the desire of making most constructors nothrow. Why?

 Andrei

 If an exception fires during the construction of an object and you 
 don't handle it your left with a partially formed object.  It becomes 
 difficult to then make that object an invariant.  This is particularly 
 bad when it occurs in the base classes constructor.

 
 But C++ solved this by making it impossible to obtain a 
 partially-constructed object. If the constructor throws, there's never 
 an object to talk about.
 
 Andrei

That's a good point, I guess the issue I've had in the past is with 
resource handles and dangling pointers.

What if the object creates a handle to a resource in the constructor 
just before the exception.  That resource never gets cleaned up unless 
your explicitly handle it with a try-catch.  Other then the out of 
memory one, I'm not aware of any C++ standard library that throw in the 
constructor.

-Joel

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Janderson wrote:
 Andrei Alexandrescu wrote:
 Janderson wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_p
ogramming_language/ 

 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we 
 could
 always do this manually, but it might be worth considering making 
 on by
 default for constructors.
 -Joel

 Please, please, please, please, *please* no!!!  Anything that is in 
 any way
 similar to checked exception Hell in Java does not belong in D.  
 Nothrow is a
 great feature precisely because, by being a contract that is only 
 enforced when
 the programmer explicitly asks for it to be, it can be simply 
 ignored in places
 where one doesn't want to use it.  Making nothrow the default in 
 constructors
 really smacks of Java-style bondage and discipline, and a major 
 reason why I use D
 is to avoid such things.  If nothrow is the default *anywhere*, it 
 will lead to
 aggravation and error swallowing similar to Java's checked exceptions.

 I agree. Bondage and discipline, heh :o). I'm actually surprised at 
 the desire of making most constructors nothrow. Why?

 Andrei

 If an exception fires during the construction of an object and you 
 don't handle it your left with a partially formed object.  It becomes 
 difficult to then make that object an invariant.  This is 
 particularly bad when it occurs in the base classes constructor.

 But C++ solved this by making it impossible to obtain a 
 partially-constructed object. If the constructor throws, there's never 
 an object to talk about.

 Andrei

 
 That's a good point, I guess the issue I've had in the past is with 
 resource handles and dangling pointers.
 
 What if the object creates a handle to a resource in the constructor 
 just before the exception.  That resource never gets cleaned up unless 
 your explicitly handle it with a try-catch.

Either you encapsulate the resource itself in its own object, or you use 
try/catch like in any other function. It's a solved problem.

 Other then the out of 
 memory one, I'm not aware of any C++ standard library that throw in the 
 constructor.

Many STL container constructors throw whatever exceptions the held 
type's various constructors throw. Besides, why would you consider out 
of memory errors somehow different?


Andrei

Janderson <ask me.com> writes:

Andrei Alexandrescu wrote:
 Janderson wrote:
 Andrei Alexandrescu wrote:
 Janderson wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_p
ogramming_language/ 

 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we 
 could
 always do this manually, but it might be worth considering making 
 on by
 default for constructors.
 -Joel

 Please, please, please, please, *please* no!!!  Anything that is 
 in any way
 similar to checked exception Hell in Java does not belong in D.  
 Nothrow is a
 great feature precisely because, by being a contract that is only 
 enforced when
 the programmer explicitly asks for it to be, it can be simply 
 ignored in places
 where one doesn't want to use it.  Making nothrow the default in 
 constructors
 really smacks of Java-style bondage and discipline, and a major 
 reason why I use D
 is to avoid such things.  If nothrow is the default *anywhere*, it 
 will lead to
 aggravation and error swallowing similar to Java's checked 
 exceptions.

 I agree. Bondage and discipline, heh :o). I'm actually surprised at 
 the desire of making most constructors nothrow. Why?

 Andrei

 If an exception fires during the construction of an object and you 
 don't handle it your left with a partially formed object.  It 
 becomes difficult to then make that object an invariant.  This is 
 particularly bad when it occurs in the base classes constructor.

 But C++ solved this by making it impossible to obtain a 
 partially-constructed object. If the constructor throws, there's 
 never an object to talk about.

 Andrei

 That's a good point, I guess the issue I've had in the past is with 
 resource handles and dangling pointers.

 What if the object creates a handle to a resource in the constructor 
 just before the exception.  That resource never gets cleaned up unless 
 your explicitly handle it with a try-catch.

 
 Either you encapsulate the resource itself in its own object, or you use 
 try/catch like in any other function. It's a solved problem.

Maybe there should be some sort of way to detect handles that are not 
RAII handled in the constructor?   You have to handle these anyway right ?

 
 Other then the out of memory one, I'm not aware of any C++ standard 
 library that throw in the constructor.

 
 Many STL container constructors throw whatever exceptions the held 
 type's various constructors throw. Besides, why would you consider out 
 of memory errors somehow different?

I guess that just about every function is a candidate for out of memory 
exceptions.  You can handle it of course at the base of the program 
however to make some exception safe you'd alway have to handle the 
memory condition which is way to tedious, particularly when you might 
already know how much memory is available.

 
 
 Andrei

Fawzi Mohamed <fmohamed mac.com> writes:

I have the impression this whole argument comes from the need to 
sidestep bugs in C++  compilers when releasing the memory of partially 
constructed objects one gets when an exception is thrown by the 
constructor.
D has a garbage collector, this cleanly sidesteps the whole problem, so 
there is no reason to have nothrow in constructors.

Fawzi
On 2008-10-02 17:27:50 +0200, Janderson <ask me.com> said:

 Andrei Alexandrescu wrote:
 Janderson wrote:
 Andrei Alexandrescu wrote:
 Janderson wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_programming_language/







Perhaps 
 
 now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we could
 always do this manually, but it might be worth considering making on by
 default for constructors.
 -Joel

 
 Please, please, please, please, *please* no!!!  Anything that is in any way
 similar to checked exception Hell in Java does not belong in D.  Nothrow is a
 great feature precisely because, by being a contract that is only enforced when
 the programmer explicitly asks for it to be, it can be simply ignored in places
 where one doesn't want to use it.  Making nothrow the default in constructors
 really smacks of Java-style bondage and discipline, and a major reason 
 why I use D
 is to avoid such things.  If nothrow is the default *anywhere*, it will lead to
 aggravation and error swallowing similar to Java's checked exceptions.

 
 I agree. Bondage and discipline, heh :o). I'm actually surprised at the 
 desire of making most constructors nothrow. Why?
 
 Andrei

 
 If an exception fires during the construction of an object and you 
 don't handle it your left with a partially formed object.  It becomes 
 difficult to then make that object an invariant.  This is particularly 
 bad when it occurs in the base classes constructor.

 
 But C++ solved this by making it impossible to obtain a 
 partially-constructed object. If the constructor throws, there's never 
 an object to talk about.
 
 Andrei

 
 That's a good point, I guess the issue I've had in the past is with 
 resource handles and dangling pointers.
 
 What if the object creates a handle to a resource in the constructor 
 just before the exception.  That resource never gets cleaned up unless 
 your explicitly handle it with a try-catch.

 
 Either you encapsulate the resource itself in its own object, or you 
 use try/catch like in any other function. It's a solved problem.

 
 Maybe there should be some sort of way to detect handles that are not 
 RAII handled in the constructor?   You have to handle these anyway 
 right ?
 
 
 Other then the out of memory one, I'm not aware of any C++ standard 
 library that throw in the constructor.

 
 Many STL container constructors throw whatever exceptions the held 
 type's various constructors throw. Besides, why would you consider out 
 of memory errors somehow different?

 
 I guess that just about every function is a candidate for out of memory 
 exceptions.  You can handle it of course at the base of the program 
 however to make some exception safe you'd alway have to handle the 
 memory condition which is way to tedious, particularly when you might 
 already know how much memory is available.
 
 
 
 Andrei

Janderson <ask me.com> writes:

Janderson wrote:
 Andrei Alexandrescu wrote:
 Janderson wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_p
ogramming_language/ 

 Perhaps now constructors can enforce no-throw.  Functions that have
 throw would have to be handled in that constructor.  Of course we 
 could
 always do this manually, but it might be worth considering making 
 on by
 default for constructors.
 -Joel

 Please, please, please, please, *please* no!!!  Anything that is in 
 any way
 similar to checked exception Hell in Java does not belong in D.  
 Nothrow is a
 great feature precisely because, by being a contract that is only 
 enforced when
 the programmer explicitly asks for it to be, it can be simply 
 ignored in places
 where one doesn't want to use it.  Making nothrow the default in 
 constructors
 really smacks of Java-style bondage and discipline, and a major 
 reason why I use D
 is to avoid such things.  If nothrow is the default *anywhere*, it 
 will lead to
 aggravation and error swallowing similar to Java's checked exceptions.

 I agree. Bondage and discipline, heh :o). I'm actually surprised at 
 the desire of making most constructors nothrow. Why?

 Andrei

 If an exception fires during the construction of an object and you 
 don't handle it your left with a partially formed object.  It becomes 
 difficult to then make that object an invariant.  This is 
 particularly bad when it occurs in the base classes constructor.

 But C++ solved this by making it impossible to obtain a 
 partially-constructed object. If the constructor throws, there's never 
 an object to talk about.

 Andrei

 
 That's a good point, I guess the issue I've had in the past is with 
 resource handles and dangling pointers.
 
 What if the object creates a handle to a resource in the constructor 
 just before the exception.  That resource never gets cleaned up unless 
 your explicitly handle it with a try-catch.  Other then the out of 
 memory one, I'm not aware of any C++ standard library that throw in the 
 constructor.
 
 -Joel

Maybe there should be some sort of way to detect handles that are not 
RAII handled in the constructor?

-Joel

Sean Kelly <sean invisibleduck.org> writes:

Janderson wrote:
 
 What if the object creates a handle to a resource in the constructor 
 just before the exception.  That resource never gets cleaned up unless 
 your explicitly handle it with a try-catch.  Other then the out of 
 memory one, I'm not aware of any C++ standard library that throw in the 
 constructor.

Yup, which is why it's possible to wrap the class member initializer 
block in a try/catch if you want to.  The language was clearly designed 
to support exception use in ctors.


Sean