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

[Stefan Behnel]

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.

Stefan