These are chat archives for jshttp/jshttp

15th
Dec 2014
Alan Plum
@pluma
Dec 15 2014 17:35
How do you tell http-errors errors apart from regular errors?
I guess httpErrors[err.status] === err.constructor could work, but that's awful.
I'll just use typeof err.statusCode === 'number' and pray for the best.
Douglas Wilson
@dougwilson
Dec 15 2014 18:47
So the idea is that you should really need to tell if it is one or not. What is the reason you are trying to identify them?
Alan Plum
@pluma
Dec 15 2014 19:15
The idea is that I can use http-errors in a client and distinguish API errors from other JS errors (e.g. SyntaxError when parsing the body, or connection errors).
I know that http-errors is primarily intended for the server-side, but I previously used httperr for both and it just makes sense to have one library for both, as error objects are really just shared data objects.
e.g., an XHR wrapper shouldn't handle HTTP errors, so my API wrapping the XHR wrapper would only generate http-errors errors if the XHR wrapper didn't throw an error and pass on the XHR wrapper's error otherwise. The code using the API then just needs to distinguish between the different http-errors errors it can handle and report an unexpected error otherwise. But it seems iffy to just check for statusCode and assume any error with a statusCode is an http-errors error.
Douglas Wilson
@dougwilson
Dec 15 2014 20:48
Gotcha. So on the server side, we actually only do detection based on err.status || err.statusCode since many libraries don't use http-status and we don't want to require them to. You could say our interface is exactly what you were doing.
Then we can see if there is a better way
Alan Plum
@pluma
Dec 15 2014 20:54
Yes, that's what I'm doing now. It just feels more fragile than if (error instanceof httperr.HttpError), analogous to if (error instanceof SyntaxError)