DZ-Jay wrote: > On Dec 1, 2007, at 13:36, Arno Garrels wrote: > >> Have you got any exception that was raised from TWSocket internaly? >> I mean outside of your handler? > > Well, I noticed the issue because my handler raised an unhandled > exception and the application then behaved in a strange manner because > it was never caught (just absorbed by ASyncReceive).
Yes, I noticed that yesterday as well when I was debugging a client pool. I got an error on ReallocMem() in TriggerDataAvailable in TCustomLineWSocket, the the destructor was called and raised an EInvalidPointer on FreeMem(), most likely due to the attempt to access and free an already freed object (most likely my fault in this case) but it took me several hours yesterday to find the problem since clients just disapeared silently unless I ran the server in the debugger. > But then looking > deeper, I found that at least SmtpProt and FtpProt *can* raise > exceptions in the WSocketDataAvailable event (not that they have). In > particular, the obvious exception they raise is if the FNext pointer > is NULL and its processing ExecAsync. > > Admittedly that should never happen, but ignoring it is just asking > for trouble (which is why I think Francois added the check and the > exception there). Also, the buffer manipulations performed there > could theoretically fail, and an exception would not be caught, yet > the component would be in a strange state. Yes, for instance ReallocMem() may raise EOutOfMemory, got this twice yesterday while stressing a server application with thousands of connections. > > Perhaps wrapping those handlers in a try..except block would be > better. It's something Francois should have a look at when he has some time. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
