2 ms·

I think null at least is a great example of their point since many applications might not want a "null" type. Although I am not sure I would go as far as to dr

• bArray 6y ago
  I think booleans might even be the most problematic, as it's _really_ implementation specific. In C for example you might expect 1 == TRUE, but in other languages this is not the case. The real problems come in when you handle unexpected cases - and there's no real answer as to whether you return true, false or an error. Personally I think the responsibility should be thrown back at the coder. E.g. I will sometimes do: if(!(jobj.get("key", "true").contains("f")))fun(); Where "true" is considered safe and default. Generally you need to make some effort to switch it off by making sure an "f" exists somewhere, but either case is fine. Imagine for example that the value "true" turns on something potentially dangerous, you might want to guard against accidentally switching it on with: if(jobj.get("key", "false").equals("true"))fun(); So you for sure have to make sure the string is "true" to switch it on, nothing else.