Question: I would like to know to know why UART errors occur, and when one should check for such errors. There is a post on here that asks about handling individual errors, such as overrun, parity, etc... I am clear on why data overrun happens, why parity error happens, but I would like to know what is the root cause. My question is more focused on why these errors could occur (physical reasons), and when one should do make error checking a factor for their application.

So far my program seems to work great (with no error checking), but I know that noise can mess things up. How could I simulate conditions that could cause the UART Rx/Tx ports to fail?

Answer: 
Most errors stem from three causes: (1) the transmitter's generated signal did not represent valid data; (2) the transmitter's signal was not received as generated, or (3) the receiver was not ready to handle the data when it was received. The most common cause I've seen for problem #1 is a transmitter that gets reconfigured or shut down while it is transmitting data. Problem #2 can easily occur for signals traveling through the "outside world" as a result of things like radio interference (mobile phones can be surprisingly nasty!), but should generally not occur for signals confined to a single board. Problem #3 can either occur because too many bytes arrive faster than they can be processed, or because the receiver is reconfigured, shut down, or started up during a transmission.

In many cases, it's difficult to completely eliminate all of these problems; one's goal should be to ensure that the total "damage" done by them (probability of occurrence, times damage per occurrence) is acceptably low. This can most easily be done by choosing a pessimistic estimate of reliability, and then designing a protocol so that the impact on system performance of even the worst failures that were consistent with one's estimates would be within acceptable limits.
In order to deal with these errors, you must implement a higher level logical protocol. something akin to TCP, or check the OSI stack for ideas. 

basically, two important parts to start with are checksums, and timeouts. use an algorithm to compute a redundent value that represents, in a smaller form, the contents of each message. then check this in the received message. if the sums don't match, you have possibly gotten a framing error, bit noise, etc, etc. and you'll need to discard the message and attempt some sort of recovery, resend, NACK ( not acknlowledged )signal, etc.

also, make sure to implement timeouts in your upper level protocol. if you get some kind of framing error, your UART may never recover and begin processing again. it may be waiting for the stop bit on a frame that the sender UART thinks has already been sent, but was corrupted by noise , clock skew, etc. this will send any input code into an infinite loop. make sure that you have a sane limit as to how long your input reading should wait until deciding to abandon this message, and again, retry, NACK, abandon, etc.