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 <d...@caribe.net> 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 http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > -- 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 http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
