W3C home > Mailing lists > Public > public-webapi@w3.org > February 2007

Re: [XHR] ISSUE-101: Network errors for sync requests

From: mikewse <mikewse@hotmail.com>
Date: Tue, 27 Feb 2007 07:52:15 -0800 (PST)
Message-ID: <9185011.post@talk.nabble.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT