Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object

Jim Ley wrote:
> 
> "Jonas Sicking" <jonas@sicking.cc>
>>> Why do we need to find a solution for error handling? I thought that 
>>> wasn't necessary for "version 1.0".
>>
>> Not having error handling at all will seriously cripple the usefulness 
>> of the spec.
> 
> We've survived so far without error handling other than magic (and 
> incomprehensible) status numbers from IE's implementation, and nothing 
> from anywhere else.  Errors are rare, and thus virtually nothing you can 
> do as an author ("the network's no longer there", erm okay then connect 
> to this site and ...)

In IE you can at least test for .status == 200 to test if things worked 
out ok. Even though the statuscode for various errors seem to be weird 
to say the least, at least they are different from the success codes.

I actually think this is how we should do errorhandling for now since 
that should work with most existing content.

> So I don't think error handling is important, as long as an error 
> doesn't look like a valid response and readyState change fires and goes 
> to 4, then errors will be generally handled the same as any other 
> malformed response coming back from the server.

So without any errorhandling I think we're in a bad place:

If we do go to state 4 then things will look almost exactly like a 
successful response. The only difference is that .responseXML will be 
null, but that is already the case for a lot of consumers that send 
non-xml data.

If we don't go to state 4 I think there's a big risk that scripts will 
just hang waiting for state 4 to roll around. Some scripts might have 
some timeout code, but I think that's an exception more than a rule.

/ Jonas

Received on Thursday, 13 April 2006 02:04:23 UTC