Re: [RFA 09/10] Return EXT_LANG_BT_ERROR in one more spot in py-framefilter.c

[Pedro Alves <palves@redhat.com>]

On 06/27/2017 06:31 PM, Pedro Alves wrote:
> On 04/25/2017 08:41 PM, Tom Tromey wrote:
>> While reading py-framefilter.c, I found one spot where an exception
>> could be caught but then not be turned into EXT_LANG_BT_ERROR.  This
>> patch fixes this spot.
> 
> Eek.  LGTM.
> 
> I wonder whether we could wrap the TRY/CATCHes in something
> that would do this exception handling systematically/automatically.
> Maybe:
> 
> template<typename Func>
> enum ext_lang_bt_status success
> try_py (Func &&f)
> {
>   TRY
>     {
>       f ();
>     }
>   CATCH (except, RETURN_MASK_ALL)
>     {
>       gdbpy_convert_exception (except);
>       return EXT_LANG_BT_ERROR;
>     }
>   END_CATCH  
> 
>   return EXT_LANG_BT_OK;
> }
> 
> Used like:
> 
>  return try_py ([] 
>    {
>      // old body of TRY goes here.
>    });

I gave this a quick try, but it looked ugly, not much
of an improvement.  Maybe with statement expressions
or macros it'd look better...

The way to go is actually probably to follow up on the idea
of patch #6, and actually just remove the TRY/CATCHes,
letting the exceptions propagate and catch them somewhere
higher up the chain.  Other than marshalling C++ exceptions near
Python/ext_lang entry point code, is there another reason we need
all the TRY/CATCHes?  [assuming local resource management has
been RAII-fied.]

Thanks,
Pedro Alves