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

  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.

ChangeLog
2017-04-25  Tom Tromey  <tom@tromey.com>

	* python/py-framefilter.c (py_print_single_arg): Return
	EXT_LANG_BT_ERROR from catch.
---
 gdb/ChangeLog               | 5 +++++
 gdb/python/py-framefilter.c | 1 +
 2 files changed, 6 insertions(+)
  

On 25/04/17 20:41, 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.
> 
> ChangeLog
> 2017-04-25  Tom Tromey  <tom@tromey.com>
> 
> 	* python/py-framefilter.c (py_print_single_arg): Return
> 	EXT_LANG_BT_ERROR from catch.

Patch LGTM/

Cheers

Phil
  

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.
   });

Thanks,
Pedro Alves
  

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