- From: mikewse <mikewse@hotmail.com>
- Date: Tue, 27 Feb 2007 07:52:15 -0800 (PST)
- To: public-webapi@w3.org
> I don't think this is possible given current implementations and deployed > content. I would've liked for async and sync to be more the same, but then > more that send() doesn't throw an exception as it does now... Oh yes, I realize that you would like to avoid exceptions altogether. Though, it is unfortunate to have to design two different systems for reporting failed requests. In the future (f ex if timeouts are implemented) it is quite probable that we want more details than just "failed" when we didn't get a response from the server. If different exception types for different kinds of failure is a preferred solution, then it would be nice to be able to trigger the exception from both request modes. Or are you thinking that different kinds of failure will correspond to separate event handlers? (onerror, ontimeout, ...) You are right that my suggestion has a problem with deployed content. Maybe that is relaxed if only responseText/XML throws the deferred exception? Anyway, it might be a good idea to add some emphasis to this dimension in the spec. As readyState==loaded can both mean having a successful response or no response at all, it might be a good idea to specify both cases in method/property descriptions that rely on the loaded state. (Currently I only see a global mention of this under the send method.) Best regards Mike -- View this message in context: http://www.nabble.com/Re%3A-ISSUE-101%3A-Network-errors-for-sync-requests-tf3279485.html#a9185011 Sent from the w3.org - public-webapi mailing list archive at Nabble.com.
Received on Tuesday, 27 February 2007 15:52:23 UTC