superagent: [discuss] change how errors are handled

Update: This thread is now a discussion about whether to revert the behavior where all non-2xx responses are treated as errors. Please read the comments before just posting a +1 or -1 or other comment.

The arity change is not up for discussion and no one is disagreeing with that one.

---

Currently errors are handled in the following ways:

1. If the function to a .get or a .end as an arity of two, the first will be an error and the second a response. If it has an arity of one then only the response is provided.
2. In the case of non-200 responses, no error is emitted or set and the user must check res.status

I would like to discuss the following changes:

1. No more magic for the callback. Always require an error argument to make things simpler and more obvious at the callsites. The returned “request” object from .get or .end could still emit error to allow for some “centralize” handling.
2. All non-200 responses are treated as errors. This means that we detect the response status and make an error object with a .status field as needed. We do no other response processing like detecting an error message or whatever (leaving that up to the user). In the case of some network error or other xmlhttprequest error (the current error types) we don’t set a .status since there wouldn’t be one.

The above brings a few advantages in my mind (yes the changes would be major version bump breaking).

• less ambiguous function calls by removing magic arity use
• simpler error handling at the callsite since for ajax requests, any non 2xx is a non-success and therefore an error. Making the code to act on success simpler in the common case (currently one has to constantly check res.status in the callbacks