www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Nothrow functions

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/74fx4/nothrow_functions_in_the_d_programming_language/
Sep 30 2008
parent reply 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
Oct 01 2008
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:



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.
Oct 01 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 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
Oct 01 2008
parent reply Janderson <ask me.com> writes:
Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 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
Oct 01 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Janderson wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 == Quote from Janderson (ask me.com)'s article
 Walter Bright wrote:

 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
Oct 02 2008
parent reply 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:

 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
Oct 02 2008
next sibling parent reply 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:

 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
Oct 02 2008
parent reply 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:

 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

Oct 02 2008
parent 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:








 
 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


Oct 02 2008
prev sibling next sibling parent 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:

 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
Oct 02 2008
prev sibling parent 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
Oct 02 2008