Easy software solution
An easy software solution would be to send the data twice, first receive it and then verify it. It's highly unlikely that exactly the same bits fail twice.
Maybe, for educational purposes, you can try to make an algorithm that sends a checksum.
So when sent twice, and received twice (exactly the same), it'll be verified. If this fails, your communication line would be too noisy.
Though, for a stable solution, you should always check hardware errors, as some microcontrollers simply stop receiving/sending at a hardware errors. Also if you don't like the overhead of the verification software, hardware errors actually give a good view on what happened and are likely to detect errors even withouth additional software (other than the handling).
Hardware solution
The UART itself actually has error checking built in. And when you use a correct baud-rate (something that scales nice on your clock-speed), it's unlikely to mis-receive uart characters. But for the sake of stability you should handle these errors. And if you really need to catch every character, you should even implement that it discards and asks for re-transmission on an error (as the character which generates the error should be considered lost). Also, if you happen to have a lot of errors on your UART, please note that it's likely a hardware error, i.e noise on the line or wrong baudrate
You must handle UART errors if you want to create a stable system.
over-run errors, when a new character is received before the character in the receive buffer is handled. (Your code should read characters faster than your baudrate is (short interrupt-driven uart receive code will help).
parity error, a parity bit determines wethether the complete message is odd or even (simplified) so if one bit fails, the parity bit will not correspondent with the message, thus the receiver hardware knows one bit was miscreceived. While unlikely, this won't work well if an even amount of bits fail, so that the parity is justified again.
Framing error, as UART has start and stop bits, it's possible to tell whenever you've received a complete message. When this message is too long/ too short or simply doesn't fit the settings (apart from baudrate?) it'll create a framing error.
More info in the datasheet 20.7.4 Receiver Error Flags
So at least, you should check the hardware errors, this gives quite a stable connection. Make sure you implement something that'll clear the error-registers (they might cause additional receive/sending to fail) and re-sent the message, so that the other device is 'synched' again.
Stop bits are effectively an idle signal - sending 2 stop bits just means that the receiver will sees an extra 1 bit gap between the characters.
Serial asynchronous data format is: idle (high) start bit (low) data bits (anything) optional parity (anything) stop bit (high) idle(high)
The receiver recognises the start of a character being sent as the first low transition on an idle line (start bit). No of stop bits is irrelevant.
RTS / CTS control signals are control signals they do not have any stop bits.
Best Answer
This sounds like a question coming from someone trying to emulate a UART receiver in software or an FPGA. For RS-232, they use the term mark and space. But these usually correspond, once digitized, into a '1' and '0', respectively.
UART receiver often divides up each bit time (must be known, a priori) into at least 4, but often 16 or more, sub-periods. It starts out (upon power up/reset) in a state where expecting the serial receiver line in a mark state. If the line is NOT in a mark at that moment, then it knows that it is in the middle of a transmission frame and must wait until it can synchronize. If the line is in a mark state, then it may or may not be in the middle of something and will have to wait and see. This is a problem with RS-232, if just plugging into another device while serial communications are happening or if part of a tap to monitor the asynch serial communications between two other players and have just been reset. To be absolutely sure, when coming out of reset anyway, the UART would need to observe at least N bit times (where N is the number of bits per word, and often 7 or 8, and assuming no parity option here) worth of mark followed by one bit time of space to re-synchronize up (or else N+1 bit times of space.) Many don't carry that much state around, so they can synchronize up incorrectly, if started in the middle of a stream. You will often get framing errors and occasional data bytes, until it happens to accidentally re-synchronize up correctly again. That's often been an acceptable price, too. Normally, cables are connected and devices are power up in a particular order of operation so that there's rarely any issues.
Once synchronized, though, the UART knows what to expect. It always starts with the receiver line going from a mark to a space, the needed start bit that goes for a full bit time, followed by data bits and then followed by at least one bit time worth of mark (or longer) as the stop bit. If it stays synchronized, then it will see that pattern repeated over and over again.
Part of the reason for dicing up the bit times, to something like 4X or 16X, is that the clocks used by the transmitter and the receiver aren't necessarily perfectly accurate and they are otherwise simply asynchronous to each other. So part of the synchronization that goes on in the receiver is in lining up its diced up periods to the transmitter's timing. The finer-grained that is done, the better aligned the receiver can become.