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: 
Framing errors can be caused by what @jippie mentions - the receiver has detected the start bit and where it expects the stop bit the data is inverted. This can also be due to data corruption caused by line interference impinging on the stop bit. You always need to check this for each byte received.

Parity errors occur when parity is implemented on the data link and there is a corruption that causes a parity mismatch in the received data. You always need to check this for each byte received.

Receive break is also regarded as an error although it's really an indication that the incoming data has fallen to logical zero for longer than 1 byte of data. Normally logical 1 is the "ambient" state between successive data bytes and it remains this way. It's a throw back to old telegraphy systems I think. I wouldn't bother checking this unless you were using this "feature" to indicate (say) a reset command to the receiver.

Overrun error is when a new byte is received before the previous byte was read by a CPU. Slightly different when a FIFO is involved but amounts to the same thing - valid received data is lost due to CPU slowness. Always check this before reading a byte and if the byte is part of a longer message (or command) throw the whole message/command away and somehow request the transmitter to resend the whole message/command.

Under run is not really an error but indicates to the sending UART that it's transmit buffer is empty i.e. it is requesting a new byte to transmit. You don't need to check this.
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.