This means that your data can't just be received half way - either it comes or it doesn't come at all (UDP).
Its possible to send a datagram with no checksum though, so I would certainly believe that corruption is possible. The checksum in udp is not very good either, so smaller errors won't be noticed. Also, remember datagram truncation on some systems. Thats a neat way to lose packet data.
UDP uses a 16bit checksum so in this case you don't need to worry about it. If the UDP fails the checksum it will drop the packet. I.e, look as if it never arrived to your program. So, if you're using UDP you don't have to worry about it.
Actually lemme paste in here using google-fu:
UDP used a 16 bit checksum. It is not impossible for it to have corruption, but it's pretty unlikely. In any case it is not more susceptible for corruption than TCP.
First of all, the "IP checksum" referenced above is only an IP header checksum. It does not protect the payload. See RFC 791
Secondly, UDP allows transport with NO checksum, which means that the 16-bit checksum is set to 0 (ie, none). See RFC 768. (An all zero transmitted checksum value means that the transmitter generated no checksum)
Thirdly, as others have mentioned, UDP has a 16-bit checkSUM, which is not the best way to detect a multi-bit error, but is not bad. It is certainly possible for an undetected error to sneak in, but very unlikely.
UDP uses a 16-bit optional checksum. Packets which fail the checksum test are dropped.
Assuming a perfect checksum, then 1 out of 65536 corrupt packets will not be noticed. Lower layers may have checksums (or even stronger methods, like 802.11's forward error correction) as well. Assuming the lower layers pass a corrupt packet to IP every n packets (on average), and all the checksums are perfectly uncorrelated, then every 65536*n packets your application will see corruption.
Example: Assume the underlying layer also uses a 16-bit checksum, so one out of every 2^16 * 2^16 = 2^32 corrupt packets will pass through corrupted. If 1/100 packets are corrupted, then the app will see 1 corruption per 2^32*100 packets on average.
If we call that 1/(65536*n) number p, then you can calculate the chance of seeing no corruption at all as (1-p)^i where i is the number of packets sent. In the example, to get up to a 0.5% chance of seeing corruption, you need to send nearly 2.2 billion packets.
(Note: In the real world, the chance of corruption depends on both packet count and size. Also, none of these checksums are cryptographically secure, it is trivial for an attacker to corrupt a packet. The above is only for random corruptions.)
TLDR; don't worry about it.