For the last few months I have been getting constant 'bug reports' for PouchDB in which the user sees a big red error in the console when we hit a 404. The 404 is an internal implementation to how PouchDB uses the API and its not an error, its entirely expected however on seeing that at the console web developers constantly assume something is broken.
Hey Paul, any thoughts on this? Without it we have to resort to things like https://github.com/pouchdb/pouchdb/pull/2835
Right. I understand how that can be annoying. Joe, what do you think?
My gut reaction is that 4xx response codes are for errors not for normal workflow, so this is an abuse of HTTP. I don't think we'd log 204 response code, and that probably says something closer to what you want doesn't it?
I agree 204 looks suitable, however that ship has sailed, that would be a huge breaking change for CouchDB so I dont expect it to change for an improvement that is questionable, also it doesnt just apply to the CouchDB api that we deal with, we also get it when attempting to read objecturls in chrome (not hitting a server) It is a tradeoff, but I do think the highlighted red item in the network tab is more than clear enough for developers, its not a feature I have found very useful, but within PouchDB its been fairly fustrating
I agree with Joe about sticking with HTTP and treat the 4xx range as errors, so closing this one out.
I do not agree with @linkclark and @jwalker. 404 are errors, sure, but the developer should be allowed to handle them. The fact that networking errors end up in the console but not other errors is not consistent and just plain annoying. This is why we have try/catch: so that not all errors have to bubble right up to the end user. 404 errors should be handled like other errors and there should be a way to catch them.