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

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

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

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

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.

-Joel

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

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.  Other then the out of memory one, I'm not aware of any C++ standard library that throw in the constructor.

-Joel

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.

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

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