I've been programming for over a quarter century, and I feel pretty confident that I've never written anything that could confuse 'null' with NULL. I can't even think of a language that would let you easily do this. If web forms aren't accepting NULL, then somebody probably specifically programmed the word 'null' into a filter of disallowed entries. Probably to stop clerks from entering the word 'null' to mean empty…
Yeah, Null is no problem. But thanks to code my predecessor wrote, >null< would be.
When using sequel pro with a MySQL database, typing NULL into a string field will make that field null rather than 'null', which always seemed like an odd design choice to me
Its a good compromise i think. OTherwise to update a field to null it would need a button or right clicking and selected a null option. I would expect the amount of people who actually want to enter a 'null' string is minimal...
This reasoning is probably behind some the OP's cases...
I've been programming for over a quarter century, and I feel pretty confident that I've never written anything that could confuse 'null' with NULL. I can't even think of a language that would let you easily do this. If web forms aren't accepting NULL, then somebody probably specifically programmed the word 'null' into a filter of disallowed entries. Probably to stop clerks from entering the word 'null' to mean empty…
In java + operator on strings works like this: Object a = null; String s = "foo bar " + a; // s == "foo bar null" So, it's possible to get "null" as a string downstream, when some variable that should be non-nulleable - was null. If you find such a bug and incompetently fix it by checking for "null" downstream instead of checking before turning variables into strings - you have the error from the article. Especially…
> it's possible to get "null" as a string downstream
I don't see the problem with that. Strings that contain formatted variables should be used for display only. Besides, when someone inputs his name, the input is already a string, and I don't see how you would dereference string contents.
I've been programming for over a quarter century, and I feel pretty confident that I've never written anything that could confuse 'null' with NULL. I can't even think of a language that would let you easily do this. If web forms aren't accepting NULL, then somebody probably specifically programmed the word 'null' into a filter of disallowed entries. Probably to stop clerks from entering the word 'null' to mean empty…
In java + operator on strings works like this: Object a = null; String s = "foo bar " + a; // s == "foo bar null" So, it's possible to get "null" as a string downstream, when some variable that should be non-nulleable - was null. If you find such a bug and incompetently fix it by checking for "null" downstream instead of checking before turning variables into strings - you have the error from the article. Especially…
Trying it in the console just now I see javascript does it too
>"hey "+null
"hey null"
I wonder why the language designers thought that was a good idea?
In java + operator on strings works like this: Object a = null; String s = "foo bar " + a; // s == "foo bar null" So, it's possible to get "null" as a string downstream, when some variable that should be non-nulleable - was null. If you find such a bug and incompetently fix it by checking for "null" downstream instead of checking before turning variables into strings - you have the error from the article. Especially…
Trying it in the console just now I see javascript does it too >"hey "+null "hey null" I wonder why the language designers thought that was a good idea?
The reason is that the string concatenation operation is doing a String.valueOf() on the argument, and that delegates to toString() that promises a human readable string that is relevant.
For some reason someone decided to check for null instead of the stricter option of throwing a NullPointerException. Maybe to help debugging or to follow the gist of toString().
I guess it was too late to change even in Java 0.9... Autoboxing, iterators and other newer features are more strict,so I suppose it's just one of the few irregularities left from prehistoric times...
In java + operator on strings works like this: Object a = null; String s = "foo bar " + a; // s == "foo bar null" So, it's possible to get "null" as a string downstream, when some variable that should be non-nulleable - was null. If you find such a bug and incompetently fix it by checking for "null" downstream instead of checking before turning variables into strings - you have the error from the article. Especially…
That's insane. I've known Java to be a bit verbose, but I thought it was mostly a reasonable language aside from that. I might have expected something like that from Javascript or PHP. Never in my wildest dreams would I have thought that boring old Java would interpret a null cast to a string as a literal string "null" when combining strings. Even Ruby and Python don't do that - they throw type mismatch errors instea…
Ehh, I don't really think this is a huge deal personally. Keep in mind that it is not that `(string)null` gives you the "null" string, or `((string)null).ToString()` gives you the null string. You have to use actual string concatenation to get it (Or as others have pointed out, `String.ToValue(null)`). Point being, it isn't/shouldn't be messing up your regular comparisons (Unless you turn it into a string beforehand), and you really shouldn't be checking for stuff like `null` against a string literal anyway - it's meant for displaying a human readable string, not an unambiguous string that could be converted back at a later time. If you wanted that then you should use proper serialization techniques rather then just concatenating a bunch of values.
> I doubt these issues will go away within even, say, twenty years. Much like the printing press, I'm 100% certain that the computing (and the internet specifically) is altering human written language across the world. It is just so much easier to avoid anything outside ASCII because you can be certain ASCII will always work - even though some awful MS Access -> CSV -> SQL -> SQL -> Excel -> SQL -> COBOL ETL pipeline…
I really doubt that there is any transliteration into ASCI that's acceptable to European speakers.
Eg A Ą Å Æ Ä are all different letters in most languages, not simply a pronunciation guide. I think most European languages use at least two from that list.
It's not always a computer problem. I have an O' name. There have been many college educated adults I've had to explain the difference between a quote ("), an apostrophe ('), and whatever the hell you call the character under the tilde (`). I kid, it's the grave.
The backtick and apostrophe are often used to emulate ``curly quotes,'' which makes the confusion even worse.
In old fonts, ` often displayed as ‘ and ' displayed as ’. When they wrote ``foo'', that was meant to show up as ‘‘foo’’, which was a workaround for not having characters to properly spell “foo”.