[Cython] [cython-users] C++: how to handle failures of 'new'?

[Dag Sverre Seljebotn]

On 07/03/2012 08:23 PM, Robert Bradshaw wrote:
> On Tue, Jul 3, 2012 at 11:11 AM, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>> Robert Bradshaw, 03.07.2012 19:58:
>>> On Tue, Jul 3, 2012 at 9:38 AM, Stefan Behnel wrote:
>>>> Dag Sverre Seljebotn, 03.07.2012 18:11:
>>>>> On 07/03/2012 09:14 AM, Stefan Behnel wrote:
>>>>>> I don't know what happens if a C++ exception is not being caught, but I
>>>>>> guess it would simply crash the application. That's a bit more visible than
>>>>>
>>>>> Yep.
>>>>>
>>>>>> just printing a warning when a Python exception is being ignored due to a
>>>>>> missing declaration. It's really unfortunate that our documentation didn't
>>>>>> even mention the need for this, because it's not immediately obvious that
>>>>>> Cython won't handle errors in "new", and testing for memory errors isn't
>>>>>> quite what people commonly do in their test suites.
>>>>>>
>>>>>> Apart from that, I agree, users have to take care to properly declare the
>>>>>> API they are using.
>>>>>
>>>>> Is there any time you do NOT want a "catch (...) {}" block? I can't see a
>>>>> C++ exception propagating to Python-land doing anything useful ever.
>>>>
>>>> That would have been my intuition, too.
>>>
>>> If it's actually embedded, with the main driver in C++, one might want
>>> it to propagate up.
>>
>> But what kind of a propagation would that be? On the way out, it could
>> induce anything, from side effects to resource leaks to crashes, depending
>> on what the state of the surrounding code is. It would leave the whole
>> system in an unpredictable state. I cannot imagine anyone really wanting this.
>>
>>
>>>>> So shouldn't we just make --cplus turn *all* external functions and methods
>>>>> (whether C-like or C++-like) into "except +"? (Or keep except+ for manual
>>>>> translation, but always have a catch(...)".
>>>>>
>>>>> Performance overhead is the only reason I can think of to not do this,
>>>>> although IIRC C++ catch blocks are only dealt with during stack unwinds and
>>>>> doesn't cost anything/much (?) when they're not triggered.
>>>>>
>>>>> "except -1" should then actually mean both; "except + except -1". So it's
>>>>> more a question of just adding catch(...) *everywhere*, than making "except
>>>>> +" the default.
>>>>
>>>> I have no idea if there is a performance impact, but if there isn't, always
>>>> catching all exceptions sounds like a reasonable thing to do. After all, we
>>>> have no support for catching C++ exceptions on user side.
>>>
>>> This is a bit like following every C call with "except *" (though the
>>> performance ratios are unclear). It just seems a lot to wrap every
>>> single line of a non-trivial C++ using function with try..catch
>>> blocks.
>>
>> But if users are correct about their declarations, we'd end up with the
>> same thing. I think it's worth a try.
>
> Most C++ code (that I've ever run into) doesn't use exceptions,
> because exception handling is so broken in C++ anyways.

Did you mean that most C++ code doesn't use try/except? That's true, but 
my experience is that throw is used.

Dag