dZ:  Perfect understanding.  :)

While the exception in #3 is the application's fault (my fault), I'm relying
on OnBgException to be triggered if an exception occurs inside my
OnDataAvailable event.  Either I shouldn't do this and ICS users should put
their own exception handling inside OnDataAvailable, or ICS is broken.  :(

wilfried:  The problem didn't surface until I changed ASyncReceive so that
the exception occurring on my code (OnDataAvailable) was not swallowed by
ASyncReceive.  I'm not calling Abort *after* the session is closed.  I don't
think ICS is either, even with my changes.  But OnDataAvailable is fired a
second time for the same data that was already being processed by my
OnDataAvailable at the time my exception occurred.

On Sat, Mar 27, 2010 at 1:26 PM, DZ-Jay <> wrote:

> On Mar 27, 2010, at 13:21, wilfried Mestdagh wrote:
> > These are possible untested situations. It is possible to call Abort from
> > within an event, but why should you call Abort if the session is closed?
> I think that he means that if there is an exception in the OnDataAvailable
> handler, and you trap it and call Abort(); then, since the OnDataAvailable
> event hasn't completed and returned normally, OnDataAvailable will be called
> again.
> The order of events is like this (simplified):
> 1. Data arrives and WinProc message manifold will call ASyncReceive.
> 2. ASyncReceive triggers OnDataAvailable so that application may retrieve
> buffer.
> 3. Application handles OnDataAvailable but causes exception within the
> handler.  This is the application's fault.
> 4. Exception is trapped by ASyncReceive.
> 5a. TWSocket bug:  exception is ignored by exception handler, and
> ASyncReceive exits normally.
> * This is bad because the application is now in an unstable state with an
> unhandled exception that it never knew about.
> 5b. TWSocket Modification suggested by Jon Robertson and I:  instead of
> ignoring exception, trigger OnBgException to give a chance to the
> application to deal with it.
> 6. The OnBgException trigger will either call Abort() if the handler sets a
> flag, or it will raise an exception otherwise.  The default is to raise an
> exception.
> Either way there is a problem:
> * If Abort() is called, since OnDataAvailable never finished, the buffer is
> not marked as read, and the event will be called again when the session is
> closed!
> * If an exception is raised, it will be bubbled up to the custom WinProc,
> which will call OnBgException again!
> Obviously, triggering OnBgException from ASyncReceive (5b above) is a Bad
> Idea.  But the current way (5a above) will ignore errors which put the
> application in an unstable state.
> I do not have a solution right now.
>        dZ.
> --
> To unsubscribe or change your settings for TWSocket mailing list
> please goto
> Visit our website at

Jon Robertson
Borland Certified Advanced Delphi 7 Developer
Good programming is 40% experience, 30% skill, 20% RTFM, 10% caffeine, and
5% attention to detail.
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to