On 10/24/22 18:48, Simon Marchi wrote:
> On 10/24/22 12:43, Tom de Vries via Gdb-patches wrote:
>> On 10/24/22 18:36, Pedro Alves wrote:
>>> On 2022-10-24 9:49 a.m., Tom de Vries via Gdb-patches wrote:
>>>
>>>> +#define RETHROW_ON_TARGET_CLOSE_ERROR(E)                \
>>>> +  do                                    \
>>>> +    {                                    \
>>>> +      if ((E).reason != 0)                        \
>>>> +    {                                \
>>>> +      /* Can't set the breakpoint.  */                \
>>>> +                                    \
>>>> +      if ((E).error == TARGET_CLOSE_ERROR)                \
>>>> +        /* If the target has closed then it will have deleted any    \
>>>> +           breakpoints inserted within the target inferior, as a    \
>>>> +           result any further attempts to interact with the        \
>>>> +           breakpoint objects is not possible.  Just rethrow the    \
>>>> +           error.  Don't use E to rethrow, to prevent object    \
>>>> +           slicing of the exception.  */                \
>>>> +        throw;                            \
>>>> +    }                                \
>>>> +    } while (0)
>>>
>>> Is there a reason this is a macro instead of a function?
>>
>> yes, the throw without expression.
>>
>> Do you know of a way to do this using a function?
> 
> Maybe by passing the exception object as a parameter and using:
> 
> https://en.cppreference.com/w/cpp/error/rethrow_exception
> 
> ?

Thanks for pointing out this possibility, I've tried this out, as attached.

I like the fact that we no longer throw something implicitly defined by 
a catch outside the function, which looks a bit awkward to me.

But sofar, I didn't manage to understand from reading the specifications 
of std::current_exception and std::rethrow_exception whether there will 
be copying of the exception or not, and AFAICT only the throw without 
expression guarantees to reuse the existing exception object, so I'm 
going with that instead (which I'll post in reply to Pedro).

Thanks,
- Tom