Nothrow functions

[Janderson]

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