On Sat, 24 Jun 2017 12:48:43 +0200, Sven Barth via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
>Am 24.06.2017 11:13 schrieb "Santiago A. via Lazarus" < >lazarus@lists.lazarus-ide.org>: >> >> 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 -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus