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
Visit our website at

Reply via email to