Jump to content
Fr0sT.Brutal

Exception is swallowed in TCustomWSocket.ASyncReceive

Recommended Posts

Posted (edited)

Hi all,

spent some time just now on investigating a weird bug, it happened to be a memory AV that wasn't reported or caught by my exception handlers. Finally I came to see TCustomWSocket.ASyncReceive which appeared to just silently swallow any exceptions that happen in TriggerDataAvailable. I suppose it should have HandleBackGroundException(E) shouldn't it?

 

Ver.: 8.58

File: OverbyteIcsWSocket.pas

Line: 8427

Edited by Fr0sT.Brutal
addition

Share this post


Link to post

Does seem strange the code eats errors on OnDataAvailable silently while some other events do raise an exception.

 

I've updated my version to trigger a background exception, but this change is not absolutely backward compatible, applications that don't have OnBgException assigned will now shut down with an exception window, rather than perhaps continuing to ignore the error, maybe good, maybe bad.  This won't go into SVN for a few days, until I've rebuilt and tested all my applications.

 

Angus

 

Share this post


Link to post

Why not put a try/except in you OnDataAvailable event handler?

 

Share this post


Link to post

Francois, of course this will do the trick but this means client code must meet some requirements which doesn't seem reliable to me.

Angus, well, have exceptions raised and shown could sound bad but it's really much better than have them swallowed silently IMHO. Unawareness of errors could cause mysterious AVs and other non-relative errors in random places. And all systems that claim to be robust should have bg exceptions handler already ¯\_(ツ)_/¯

Share this post


Link to post

Angus, just found that `bMore := FALSE` is still necessary... HandleBackGroundException calls OnException and stuff, then Abort is called, then socket is closed and then all these nested calls finish and... "while bMore do" loop continues :)))

Share this post


Link to post

Yes, should not have taken that out, we do need to break the loop, I'll put it back. 

 

However even that may not stop TriggerDataAvailable being called again since there may still be received data buffered,  Much nicer if there was no exception in the first place. 

 

Angus

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×