"I hadn't noticed this before since the parser is written in a way that it will ignore everything that doesn't look like JSON." and this is precisely why you w

"I hadn't noticed this before since the parser is written in a way that it will ignore everything that doesn't look like JSON." and this is precisely why you want to fail hard if you encounter invalid input. Yes. It's annoying in the cases of "nearly valid" input or "valid input but with some garbage". Yes it's more work to deal with the error. But it also means that something like this blows up before you end up in a "sometimes it works, sometimes it doesn't" situation. Yes. I have been dealing with and even preferring the silently-failing kind of functionality, but over the years I've been bitten by it too many times to still being able to prefer it with a good conscience. Overall you might still spend more time overall dealing with bitchy libraries, but at least you will hopefully never have to deal with bugs that happen only sometimes as those are really hard to track down and fix (if it's at all possible). Sure. Sometimes you can get away with "yea - it fails at times - that's an unfortunate fact of life", but the moment that issue which only rarely appears costs the customers or your money, it all becomes really important and "it fails at times" just doesn't do. Of course, by then, the problem needs to fixed right then - which just doesn't go very well with "it usually works". At that point you spend the hours it takes to track the problem down and you will curse your decision to fail silently once.