In my work, we are currently during a sort of rewrite of the biggest project our team is responsible for. The main reason was, that the current way we were doing things did not allow us to catch all the errors, since some of the errors were in the promises inside of the promises. And because of the way we rewrote it, a lot of the functions still using callbacks did start showing some weird behavior.
The main function, we were using to make HTTP calls so far was using very similar syntax to what the Postman suggest to use in its example for NodeJS - Native. We had the request with the callback, and inside of the callback we would be waiting for things like request.on("data") or request.on("end"), while the request.end() would be outside of the callback.
This no longer worked, since sometimes the function finished before the callback started, so the callback never happened. And the entire thing would failed. So I needed to find the solution for this.
The Request library has entered the maintenance mode, so this was not longer an option.
The axios library teats them as errors. I have seen blog posts putting this as the reason to use axios. Why would anybody want this? A lot of times the info in these requests is needed to even decide, what to do with it. And the only way to do this is to provide the response, including the URL and the body. I highly doubt all this information is available in the error thrown. I would like to see these people connect to one of the APIs, that return almost any error as HTTP 400.
For example, the node-fetch package even explicitly mentions, that they are not throwing error with these HTTP codes:
3xx-5xx responses are NOT exceptions and should be handled in then(); see the next section for more information.
Well, since fetch will eventually came natively to Node, it seems that the fetch way of not treating it as the errors will eventually prevail. I am happy for that day.
Until then, I guess I am going to have to be extra careful about what library am I using.