Right, definitely a bug in mx.rpc.soap.Operation#invokePendingCall where it invokes a helper method to dispatch fault events directly if it hits encoding errors, etc.
An example of what it should be doing can be seen in mx.rpc.soap.mxml.Operation#send: new AsyncDispatcher(dispatchRpcEvent, [faultEvent], 1); mx.rpc.AsyncDispatcher is a (currently @private) helper class that helps avoids Timer leaks due to overlooking cleaning up event listeners when using the old "Timer(1, 1)" idiom. Best, Seth From: [email protected] [mailto:[email protected]] On Behalf Of Josh McDonald Sent: Thursday, December 11, 2008 9:20 PM To: [email protected] Subject: Re: [flexcoders] Best practice for calling asynchronous functions? SOAPEncoder throws an exception, which is caught by Operation, swallowed, and then a fault event is dispatched from the Operation instance. If you do all your async stuff using responders because you need to know *which* action has just finished or faulted (among other things), you never get to hear about it. -Josh On Fri, Dec 12, 2008 at 2:20 PM, Mark Carter <[email protected]> wrote: Josh McDonald-4 wrote: > > The problem is that from the SDK's point of view, there is no request. > There's no IMessage, there's nothing to wait on. However from the > application's point of view, there is. > I don't quite understand... Wouldn't any problems before the async token is returned, be thrown as an exception from the method returning the async token? Therefore the calling code just needs to catch that exception and handle it. The only problem with this would be if an event is generated after the async token is returned and before the responder is added. This would only be an issue in a multi-threaded environment.
