In what field do you work? In writing public-facing applications I've never felt this way, beyond standard input validation, char-limiting, and carefully escaping outputs (htmlentities, bound parameters, etc).
A random war-story from B2B integration land... One customer system we had to interoperate with required an are credentials to be provided via an HTTP header. However it kept giving errors, until I realized that it only recognized the HTTP header when "authorization" was entirely lower-case, a sensitivity in violation of the HTTP spec.
Since our stack's own HTTP client libraries always used title-casing on the wire, we had to find a way to slot in a special exception, code to modify that header before it went out.
Another fun one is all the services which say their mime type is "application/json" while emitting generic (non-JSON) error message pages. So our logs are full of JSON decoding errors, rather than something describing what actually went wrong on the other end.
I've heard these issues referred to as "bug-for-bug compatibility" or "bug-for-bug interoperable". Making sure something works even if it is in violation of a spec since you can't change the other side of the communication.
I feel lot of that is dealing with exceptions. In sense preventing them. Exceptions can be either dealt with or prevented by handling them before they become such. So it is somehow dealing with unexpected input, or unexpected output from somewhere else. Which undealt with would result in exception.
3 an image will just crash your backend script with no way to catch the error because some bug in the image encoder/decoder you use to resize the image
4 some user browser extension inserts garbage in the requests, you need to check for it and tell the user what is wrong, otherwise same complains reach support "stuff is broken" and support needs to contact developers to check and report back that stuff was corrupted by an extension , most of the time security crap that inserts stuff everywhere
5 I had cases where an API wwas returning soem string before the real result, it was much faster to check for this case and fix it, then have the customer contact their hosting or the author of the plugin that was adding that string before each response.
Some languages lean on exception handling more heavily than others. Golang and Rust don't have them at all while, whereas Python and Java are exception town.
On one hand it kinda makes sense to handle rare cases in a way that doesn't affect the normal flow, but on the other hand having a piece of code literally try to crash the program on purpose because something didn't look quite right is a horrible idea in practice.
