When a parse error occurs from reading a network response chances are it's a network related issue. Therefore we should flow through network related information to the error handler so that users can handle the errors appropriately.
@DamianEdwards I think we can just add an .xhr property on the relevant error object. What do you think?
What about the cases where we have parse failures where there is no XHR request? Do we just want to ignore these situations and not pass any network related information to the error handler?
It's very unlikely for any other non-ajax related transports to throw parse failures due to the network since they're all long running. I'm O.K. with not passing any data for those, @davidfowl what do you think?
What network information would we pass if there's no xhr? The source property can still be set to whatever root exception caused the issue.
Added a context member to the error object.
- The context member is to provide additional information that can help identify the cause of an error.
Expanded on the response redirection facts to check that a context me…
…mber is passed on the error object.
Addressed code review comments.
- Also added extra context to errors where it made sense.
tested there is an error.context.responseText