Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2017-06

How to make debugging ignore exceptions?

7 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bo Berglund

I need to make the Lazarus debugger ignore exceptions (not stop on them), which is possible in Delphi (do not stop on language exceptions).
How can I configure Lazarus to do the same?

I have a tight loop including reading an Indy TCP client socket waiting for incoming data and I have put a try-except bracket around this read. The problem is that the debugger always stops on the exceptions making the debugging impossible (they happen with 10 ms intervals).

Code snippet;
    //First check TCP data
    try
      FTcpComm.IOHandler.ReadBytes(Buf, BufLen, false);
      if Length(Buf) > 0 then
      begin
        SerWrite(FComH, Buf[0], Length(Buf));
        SetLength(Buf, 0);
      end;
    except
      //Do nothing on timeout, does not get here
    end;
Bo Berglund Developer in Sweden

Reply by email

Bo Berglund
to Bo Berglund
Bo Berglund wrote 5 lines
I need to make the Lazarus debugger ignore exceptions (not stop on them), which is possible in Delphi (do not stop on language exceptions). How can I configure Lazarus to do the same?

I might add that I have visited:
Tools/Options/Debugger/Language Exceptions
and unchecked the box "Notify on Lazarus Exceptions" (which is a similar setting as in Delphi).
But it does not stop the IDE from breaking on the exception handler I want to debug.
I need to stop the Lazarus debugger pop-up from triggering by the exception and allow me to reach the exception handler instead. How can this be accomplished?

Bo Berglund Developer in Sweden

Reply by email

Santiago A.
to Bo Berglund: I need to make the Lazarus debugger ignore exceptions (not stop on them), which is…

El 24/06/2017 a las 0:14, Bo Berglund via Lazarus escribió: The problem is that the debugger always stops on the

exceptions making the debugging impossible (they happen with 10 ms intervals).

When I run into a program that raises a lot of exceptions in a loop, I think that I'm doing something wrong, I have missed some check or data sanitation in the loop. Exceptions are for exceptional cases. I mean, errors or unexpected cases. A case that happens each 10 ms is not an error or an exceptional case, it's one of the usual cases, and it must be handled by the natural flow of the program in a structured way. Raising continuously exceptions is not only an annoyance for debugging, but a performance problem. Exceptions may be expensive.

For example, if you are going to process a file with lines that are integers and alphanumeric strings, and you want to sum only the integers, instead of

sum:=0;
While not eof(f) do begin
  readln(f,Line);
  try
    num:=StrToInt(Line);
    sum:=sum+num;
  except
  end
end;

you should use

sum:=0;
While not eof(f) do begin
  readln(f,Line);
  val(num,Line,code);
  if code=0
     then Sum:=Sum+num;
  end;
end;

I don't know the FTcpComm component. Isn't there a way to check first if that annoying exception is going to be raised?. Probably there are functions like "IsReadDataReady" and "isSerWriteReady", so you can avoid a lot of exceptions

if FTcpComm.IOHandler.IsReadDataReady() then begin
      FTcpComm.IOHandler.ReadBytes(Buf, BufLen, false);
      if (Length(Buf) > 0) and isSerWriteReady(FOmH) then
      begin
        SerWrite(FComH, Buf[0], Length(Buf));
        SetLength(Buf, 0);
      end;
end;

Or with several retries in loops with a sleep.

Saludos Santiago A.

Reply by email

Sven Barth
to Santiago A.

Am 24.06.2017 11:13 schrieb "Santiago A. via Lazarus" <

Show quoted text 14 lines
: El 24/06/2017 a las 0:14, Bo Berglund via Lazarus escribió: The problem is that the debugger always stops on the > exceptions making the debugging impossible (they happen with 10 ms > intervals). When I run into a program that raises a lot of exceptions in a loop, I think that I'm doing something wrong, I have missed some check or data sanitation in the loop. Exceptions are for exceptional cases. I mean, errors or unexpected cases. A case that happens each 10 ms is not an error or an exceptional case, it's one of the usual cases, and it must be handled by the natural flow of the program in a structured way. Raising continuously exceptions is not only an annoyance for debugging, but a performance problem. Exceptions may be expensive.

Well, Indy abuses Exceptions for notifications and such...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170624/74d76c70/attachment.html>

Reply by email

Martin Frb
to Bo Berglund: On Sat, 24 Jun 2017 00:14:42 +0200, Bo Berglund via Lazarus I might add that I have…
Bo Berglund wrote 10 lines
I might add that I have visited: Tools/Options/Debugger/Language Exceptions and unchecked the box "Notify on Lazarus Exceptions" (which is a similar setting as in Delphi). But it does not stop the IDE from breaking on the exception handler I want to debug. I need to stop the Lazarus debugger pop-up from triggering by the exception and allow me to reach the exception handler instead. How can this be accomplished?

Do you want it to "not stop at all"
Or do you want it to "stop in the except/finally block"?

If you want to get to the finally block, then you have to stop in the except first, and then do single steps. That should take you there. There is no way to stop directly in the finally/except block.

If you do not want to stop at all, then that is "Notify on Lazarus Exceptions"
That is all exceptions by "raise ...".
Run errors are separate, so are Signals (SigSegV, Sig....). Signals can afaik not be suppressed.

"Notify on Lazarus Exceptions" just prevents the notification, internally the execution still stops, but is continued immediately. If of course your code throws hundreds of exceptions, then that still is a slow down. There is no option to prevent this.

For the handling of exceptions see
components\lazdebuggergdbmi\gdbmidebugger.pp line 5531

   procedure ProcessException;

nested in
function TGDBMIDebuggerCommandExecute.ProcessStopped

To prevent the internal stop in exceptions search the file for FExceptionBreak

You will find calls to
FExceptionBreak.SetByAddr
or
FExceptionBreak.SetBy....
FExceptionBreak.SetBoth
FExceptionBreak.SetAt...

Those need to be commented out.

Reply by email

Bo Berglund
to Sven Barth: Am 24.06.2017 11:13 schrieb "Santiago A. via Lazarus" < Well, Indy abuses Exceptions for…
Sven Barth wrote 17 lines
Am 24.06.2017 11:13 schrieb "Santiago A. via Lazarus" < >: > > El 24/06/2017 a las 0:14, Bo Berglund via Lazarus escribió: > The problem is that the debugger always stops on the > > exceptions making the debugging impossible (they happen with 10 ms > > intervals). > When I run into a program that raises a lot of exceptions in a loop, I > think that I'm doing something wrong, I have missed some check or data > sanitation in the loop. Exceptions are for exceptional cases. I mean, > errors or unexpected cases. A case that happens each 10 ms is not an > error or an exceptional case, it's one of the usual cases, and it must > be handled by the natural flow of the program in a structured way. > Raising continuously exceptions is not only an annoyance for debugging, > but a performance problem. Exceptions may be expensive. Well, Indy abuses Exceptions for notifications and such...

The problem is that afik the TIdTcpClient.IOHandler.ReadBytes will throw an exception if the number of bytes requested do not appear within the timeout.
It looks like if one specifies read length as -1, then the exception is not thrown if there are no data, it just waits for the timeout. I have yet to see a property telling me how many bytes are currently available to be read from the component...

Regarding exceptions in general, I would like to see a trap (stop on exception) if there is no defined except clause to handle it. But if there is the exception should be processed without any notification from the debugger.
One can always put a breakpoint inside the exception handler code if one wants to see what is ahppening..

Bo Berglund Developer in Sweden

Reply by email

Santiago A.
to Bo Berglund
Bo Berglund wrote 14 lines
The problem is that afik the TIdTcpClient.IOHandler.ReadBytes will throw an exception if the number of bytes requested do not appear within the timeout. It looks like if one specifies read length as -1, then the exception is not thrown if there are no data, it just waits for the timeout. I have yet to see a property telling me how many bytes are currently available to be read from the component... Regarding exceptions in general, I would like to see a trap (stop on exception) if there is no defined except clause to handle it. But if there is the exception should be processed without any notification from the debugger. One can always put a breakpoint inside the exception handler code if one wants to see what is ahppening..

|Just read this
|

https://stackoverflow.com/questions/13839094/how-to-read-all-bytes-from-server-using-indy-client-in-delphi

Saludos Santiago A. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170626/22ea5760/attachment.html>

Reply by email