Why do I get weird symbols in my variables, that cause them to break?

Sometimes when filling variables, either in Maya, or when looking at a mayaAscii file, you'll see "non-standard" characters \ symbols like:

€     // what is that, the Euro symbol?
#     // pound symbol
1.#QNAN  // found this when a camera's positions corrupted
-1.#IND // same camera problem 
1.#INF // same camera problem
1.#QO // showed up in the camera's tras channels when framing corrupt geo...
others?  (see 'e-' * 'e+' below)

Why does this happen? My best guess is that it has something to do with 'order of operation' and writing to memory: Sometimes mel commands take longer to execute than maya expects, so it will keep running code before the past command has finished. When it tries to capture the data, or fill new data while a command is still executing, problems can occur, and these weird symbols can pop up. I've see them in skin weights and path names most commonly.
How to fix? Some ideas:

• Try breaking your procedure into multiple smaller procedures, each that has a return value. Call to them in order capturing the return value, which should make Maya stop and smell the roses.
• Use evalDeferred -lp "command..." to make Maya wait until the processor becomes free to execute the command. However, this starts a slippery slope of making everything run in evalDeferred, so use sparingly.

---

Notes on €:

• I've seen this come up in a few cases (in addition to what I list below):
  • When I try to execute Python code in a mel tab of the Script Editor (oops...).
  • When the previous line didn't have a semicolon on the end: ;
  • When I was trying to capture the return value of a command, and in that command, it was being passed an arg by capturing the return value of some other command via the back-tick \ back-quote `. Like: float $val = `command -argA `getVal` -argB 4`;
• I had a script that was filling each element of a vector in a vector array with the return value from some code that maintains float precision. It was all happening on one line.
• On days 1-2, code worked fine. On day 3, it stopped working:
• When I would interactively select-execute the code in the Script Editor, I would get errors in the history: On each of the vector declaration lines, at either 125 or 126 characters, it would truncate the line, and insert a € character at the end (shown in the history of the Script Editor).
• The only solution I came up with (restarting Maya, and my machine didn't help) was to put each call to the precision code on a single line, filling a single variable, then passing that to the vector array.
• The kicker is the code that was failing was duplicated in another proc in the script, the only difference was the data was being passed to a string, rather than a vector. :-S
• I've had this show up in other places, and in those cases I found the problem: I was evaluating a string, and escaping some variable names I'd passed inside. I had one too many escape characters '\', and for some reason the extra escape char was causing this symbol to appear.
• Another example: I was sourcing a script, and in that script was a procedure being called to with arguments. The arguments were concatenated strings, but in on case, I forgot to add the end parenthesis, and got this as part of Maya's error. As you can see, there is a missing parenthesis in there, causing the next argument to really get confused...
  • The source line being eval'd looked like this:

...rigDir, (assetDir+"/build/", "S:/assets/rigs/shared/")});

• Notice, the mistake with the parenthesis ')' missing after /build/ and an extra ')' after /shared/?
• This is the error code that Maya spit out:

...$rigDir,  ($assetDir+"/build/", "S:/a€ // 

---

Here's an example of bad data, from a script I was writing:

file  -f -chn 1 -con 0 -exp 1 -ch 1  -typ "mayaAscii" -es c:/temp/asse€

The end asset path was a variable I had passed into this command. But for whatever reason due to previous evaluation issues, it wasn't able to store the full path value, so it failed.
It should be said that sometimes you'll see numbers like this:

8.881784197e-018
8.881784197e+018

The e- isn't a "bug" it's saying that it's 18 decimal places over: A very very small number!:
If I detect e- in my number, I usually just set it to zero.
e+ is the same thing, but it's saying it's a HUGE number.