Nothrow functions

[Fawzi Mohamed]

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 at me.com> said:

> Andrei Alexandrescu wrote:
>> Janderson wrote:
>>> Andrei Alexandrescu wrote:
>>>> Janderson wrote:
>>>>> Andrei Alexandrescu wrote:
>>>>>> dsimcha wrote:
>>>>>>> == Quote from Janderson (ask at 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