[fpc-pascal] FPCUnit test + raise E;

[Sven Barth]

On 17.09.2013 17:18, Marcos Douglas wrote:
>>> I implemented -- but not up to Git yet -- some like that:
>>> procedure TghSQLHandler.DoOnException(E: Exception);
>>> var
>>>     NewEx: EghSQLError;
>>> begin
>>>     if Assigned(FOnException) then
>>>       FOnException(Self, E)
>>>     else
>>>     begin
>>>       NewEx := EghSQLError.Create(Self, E.Message);   // <<<
>>>       NewEx.InnerException := E;                                  // <<<
>>>       raise NewEx;
>>>     end;
>>> end;
>>>
>>> So, if I recreate the Exception, it works in any cases. As you see, I
>>> created a new property (InnerException) to save the original
>>> exception to know what the real Exception happened...
>>> But I think this introduces much more overhead to processing.
>>
>>
>> Can you access fields of the InnerException? Maybe it's a problem of
>> reraising an existing exception...
>
> Yes, I have access but no, this is not the problem. I had coded
> InnerException property after the problem to solve it, creating a new
> Exception but not missing the original one.

Was just an idea that something got freed while you didn't expect it to 
get freed...

>>> In my code I have classes that inherited from TghSQLHandler. This
>>> class have the DoOnException method.
>>> So DoOnException can be call many times in override methods. Maybe the
>>> program "broke" the stack because "raise E" can be call and raise an
>>> exception; the next "level" raise another; and next call again.  :/
>>
>>
>> Could possibly be. If you could reproduce it in an as simple example as
>> possible that would help.
>
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> In attachment.
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Will take a look when I find the time (or someone else of the devs can 
take a look as well ^^)

>> Another thing you could try (just for testing): change your exception
>> handler procedure to a function that returns bool and use it like this:
>>
>> === code begin ===
>>
>>
>> procedure TghSQLConnector.Connect;
>> begin
>>    try
>>      FLib.Connect;
>>    except
>>      on E: Exception do
>>        if not DoOnException(E) then
>>          raise;
>>    end;
>> end;
>>
>> === code end ===
>>
>>
>> Regards,
>> Sven
>
> The only difference is the use of raise; instead raise E; right?

Basically, yes. But "raise;" can only be used inside an "except ... end" 
block, so it would not compile inside your DoOnException method.

Regards,
Sven