Re: Extra information in the message string of exceptions.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2022-06-06 20:40, G.B. wrote:
> On 06.06.22 15:40, Fabien Chouteau wrote:
>> On Monday, June 6, 2022 at 3:02:25 PM UTC+2, roda...@gmail.com wrote:
>>> For instance, a Constraint_Error message might provide details on
>>> the variable name, the legal range and the erroneous value which caused
>>> the exception.
>>
>> That's a really good idea I would say. Extremely useful during 
>> development where I often start the debugger just to know what value 
>> triggered a Constraint_Error.
>>
>> I guess the drawback is performance as formatting string with extra 
>> information will have a cost.
>> But this feature could be activated with a switch only when needed.
> 
> Will it help to have a standard object taking just the data?

Besides problems with finalization and touching memory pools, an 
exception from a rendezvous is propagated in two tasks. Will the object 
be shared, copied?

------------------
Though you can always serialize an object into a string stream and use 
the result. One could consider some syntax sugar like:

    raise E with X;

would mean

    declare
       S : aliased String_Stream (200);
    begin
       T'Output (S'Access, X); -- T is the subtype of X
       raise E with S.Get;
    end;

and

    function Stream (X : Exception_Occurrence)
       return not null access Root_Stream_Type'Class;

So, in the handler:

    when Error : E =>
       declare
          X : T'Class := T'Class'Input (Error'Stream);
       begin
          ...
       end;

without the sugar:

    when Error : E =>
       declare
          S : aliased String_Stream (200);
       begin
          S.Set (Exception_Message (S));
          declare
             X : T'Class := T'Class'Input (S'Access);
          begin
             ...
          end;
       end;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de