Hi,

1) I have a code like that:

procedure TghSQLConnector.Connect;
begin
  try
    FLib.Connect;
  except
    on E: Exception do
      DoOnException(E);
  end;
end;

https://github.com/mdbs99/Greyhound/blob/0.1.8/src/ghsql.pas#L1565

2) DoOnException was implemented so:

procedure TghSQLHandler.DoOnException(E: Exception);
begin
  if Assigned(FOnException) then
    FOnException(Self, E)
  else
    raise E;
end;

https://github.com/mdbs99/Greyhound/blob/0.1.8/src/ghsql.pas#L443

So, as you see, if occurs a Exception the code checks if the event (OnException) was setted. If yes, call user implementation; if no, call raise E;
It works... but not when I uses in FPCUnit tests.

See a simple test (this works):

procedure TghSQLConnectorTest.TestOnException;
begin
  // catch
  FConn.OnException := @DoOnException;
  FConn.Script.Text := 'foo';
  FConn.Execute;
end;

https://github.com/mdbs99/Greyhound/blob/0.1.8/test/ghsqltest.pas#L246

The code DoOnException is:

procedure TghSQLTest.DoOnException(Sender: TObject; E: Exception);
begin
  AssertTrue(Assigned(E));
end;

https://github.com/mdbs99/Greyhound/blob/0.1.8/test/ghsqltest.pas#L141

So, if I change the test like bellow... BUM! SIGSEGV!!

procedure TghSQLConnectorTest.TestOnException;
begin
  // removed >>> FConn.OnException := @DoOnException;
  FConn.Script.Text := 'foo';
  FConn.Execute;
end;

The ERROR is:
[Content]
Project test raised exception class 'External: SIGSEGV'.

At address 40B758

Can you explain this?

Marcos Douglas

I forgot. I'm using Lazarus 1.1 r42461 FPC 2.6.2 i386-win32-win32/win64 I want to know if there is a problem in FPCUnit to catch some exceptions. That's all.

Marcos Douglas

FPCUnit and DUnit and FPTest frameworks have special test methods for testing exceptions. In the latter two frameworks it is CheckException(). I know FPCUnit has something similar. I think for the DUnit compatibility interface of FPCUnit I implemented the CheckException method too.

G.

Could you as a test replace the

raise E

with

raise E at get_caller_addr(get_frame), get_caller_frame(get_frame);

and check whether this makes a difference?

Could you also compile the RTL with debug information and maybe also without optimizations (CROSSOPT="-gl -O-") and rerun your test and display the stack trace (you'll need to enable "-gl" for your test as well)?

Regards,
Sven

I tried. No makes difference.
(could you explain which the difference to call "raise" using "raise E at [...]"?)

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.

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. :/

I will try too.

Marcos Douglas

The raise-at statement allows you to raise an exception for a specific address. This allows you to have e.g. a error handling procedure (to wrap a more compilated generation of a exception class) but have the exception address still point to the original call site. E.g.:

=== code begin ===

procedure Error(aArg: Boolean);
begin
   if aArg then
     raise Exception.Create('Test')
   else
     raise Exception.Create('Test') at get_caller_addr(get_frame),
get_caller_frame(get_frame);
end;
procedure Test1;
begin
   Error(True);
end;
procedure Test2;
begin
   Error(False);
end;
begin
   try
     Test1;
   except
     DumpExceptionBackTrace(Output);
   end;
   try
     Test2;
   except
     DumpExceptionBackTrace(Output);
   end;
end;

=== code end ===

In case one the stack trace will contain Test1 and Error in case two the stack trace will be only Test2.

Can you access fields of the InnerException? Maybe it's a problem of reraising an existing exception...

Could possibly be. If you could reproduce it in an as simple example as possible that would help.

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

Ok, thanks for the explanation!

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.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
In attachment.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The only difference is the use of raise; instead raise E; right?

Marcos Douglas

In project in attachment before, if you change the line 50 from:

    raise E;

to:
    raise Exception.Create(E.Message);

Will work... but is this correct?

Lazarus 1.1 r42461 FPC 2.6.2 i386-win32-win32/win64

Best regards,
Marcos Douglas

PS: Sorry for my late, Sven.

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

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

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

Regards,
Sven

So this seems to be indeed a problem of freeing exceptions. Whether you misuse the exception system or you encountered a bug needs to be determined...

Lazarus 1.1 r42461 FPC 2.6.2 i386-win32-win32/win64

Could you test your original one with 2.7.1 as well?

PS: Sorry for my late, Sven.

No problem. :)

Regards,
Sven

If this is a bug I can register in bug tracker.

> Lazarus 1.1 r42461 FPC 2.6.2 i386-win32-win32/win64 Could you test your original one with 2.7.1 as well?

I can't compile Lazarus with FPC 2.7.1 (as you saw in lazarus-list) so, I can't test... :(

> PS: Sorry for my late, Sven. No problem. :)

Thanks,

Marcos Douglas

"Marcos Douglas" wrote

On Tue, Sep 17, 2013 at 2:41 PM, Sven Barth

> On 17.09.2013 17:27, Marcos Douglas wrote: >> >> On Tue, Sep 17, 2013 at 12:18 PM, Marcos Douglas

>>>> >>>> Another thing you could try (just for testing): change your exception >>>> handler procedure to a function that returns bool and use it like

this:

I don't know yet whether it's a bug or a mistake...

It's ok if you use a 2.7.1 before the merge of the cpstrrtl branch. There AFAIK weren't any exception related changes since then.

Regards,
Sven

For now I resolved use re-raise the original Exception using FPC 2.6.2.

Thank you again.

Marcos Douglas