[gabesullice]

> It helpfully spits out this HTML response in return but, of course, my frontend code was expecting a JSON response. I had no idea I was ever going to get anything different.

I wish more front-end devs recognized that they're building HTTP clients whenever they make HTTP requests. There's a whole specification written about how to do that well so one doesn't have to learn things like this the hard way. Specs may look old and esoteric, but following them bakes hard-earned wisdom into your apps for free.

[PcChip]

Isn't there some kind of library to handle this without having to code it each time?

[raxxorraxor]

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.

[gabesullice]

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)

[ValCanBuild]

I've found often in my career that, sadly, learning things the hard way is usually the best way to remember the lessons.

[gabesullice]

Hey, me too! Thanks for writing up your experience and publishing it btw.

I think you did a great job cementing the "why"—usually this topic is very hypothetical. I also liked how you tied it to real end users. After all, that's who the internet is for!! [1]

My intention wasn't to criticize your post. I hoped my comment would help one or two readers recognize the underlying problem space a little sooner, which might help them learn a more broadly applicable lesson when the time comes.

[1] https://www.rfc-editor.org/rfc/rfc8890.html