There is a HTTP status code in any response and a 403 like in this case should already inform you about the problem. Pretty high level already.
I prefer to let the users actually see such errors, although that seems to be an anti-pattern today.
Usually any message receiver should first check the status code and only proceed if it is 2xx and handle errors in any other case.
But such edge case errors (a 403 usually isn't an edge case) getting swallowed still happens on the most prominent on thoroughly tested sites. Had similar stuff on Amazon and Microsoft pages for example. Saw the errors in the console but they weren't displayed to the user.
Yes and no. A library might check for the status codes, but then what? Will it throw an exception? You'll have to catch them.
Will it fail silently? If so, is your code prepared for null to be returned instead of parsed JSON objects. You'll have to check for that.
Using a library isn't going to save you from handling all the error states and unexpected response bodies. It'll just change the documentation you're reading and the name of the abstractions you're dealing with (e.g. status codes -> exceptions)
I prefer to let the users actually see such errors, although that seems to be an anti-pattern today.
Usually any message receiver should first check the status code and only proceed if it is 2xx and handle errors in any other case.
But such edge case errors (a 403 usually isn't an edge case) getting swallowed still happens on the most prominent on thoroughly tested sites. Had similar stuff on Amazon and Microsoft pages for example. Saw the errors in the console but they weren't displayed to the user.