Re: ISSUE-101: Network errors for sync requests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ISSUE-101: Network errors for sync requests

mikewse
To be able to report network errors in a consistent way for asynchronous and synchronous requests, XHR could make use of deferred exceptions for the async case (assuming that sync requests will continue to throw NETWORK_ERR in future specs).
 
This could be done by letting all properties that are results of the response throw a deferred NETWORK_ERR. Thus, a client script that sends an asynchronous XHR request and doesn't check on the response's status or content will not encounter the exception (which makes sense as it apparently isn't interested in the result).
But a script checking response status or content will have the correct exception thrown at inspection time. See example below, where a network error would cause a deferred exception to be thrown at the test for "this.status == 200".
 
function handler() {
    if (this.readyState == 4) {
        try {
            if (this.status == 200) {
                ...
            }
        }
        catch(netErr) {
            ...
        }
}
var client = new XMLHttpRequest();
client.onreadystatechange = handler;
client.open("GET", "test.xml");
client.send();
 
This would offer a similar solution for async requests as for the synced, and throws exceptions at a point where they may be caught instead of going straight into the global error handler, which has been discussed as a problem earlier on.
 
Best regards
Mike Wilson
Reply | Threaded
Open this post in threaded view
|

Re: ISSUE-101: Network errors for sync requests

Anne van Kesteren-2

On Thu, 22 Feb 2007 16:51:30 +0100, Mike Wilson <[hidden email]>  
wrote:
> But a script checking response status or content will have the correct
> exception thrown at inspection time. See example below, where a network
> error would cause a deferred exception to be thrown at the test for
> "this.status == 200".
> [...]

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...


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: ISSUE-101: Network errors for sync requests

mikewse
> 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