First off, many block modes of operation require a message to be padded so that its length is evenly divisible by the block size of the cipher. CBC mode (Cipher Block Chaining), for instance, typically pads a message either with an entire block of zeroes if it happens to be exactly divisible by the block size, or with a given number of bytes that will extend the message to the next block, each of those bytes being set to the number of bytes added as padding (one byte set to 0x01, two bytes set to 0x02, 16 bytes set to 0x10, etc).
Now, you have a checksum of sorts built into the message. If the last block of the message, when decrypted, doesn't have valid padding, then the decryption has failed; either the message was corrupted in transit (CBC mode results in a "cascading" of error due to the XORing of the previous ciphertext block with the current plaintext block before encrypting), or the key used to decrypt was incorrect. An application for file encryption that uses some other sort of integrity check, such as mirroring/parity, could verify that the data is OK, and thus the only other explanation is that you used the wrong key.
As an aside, a system that can tell you whether a particular ciphertext message was properly padded is known as a "padding oracle", and it is a vulnerability of modes like CBC, because the cipher (initialized by the legitimate user with the proper key) can be fed a series of "chosen ciphertexts" to try to decrypt, each based on combinations of the real ciphertext and some random data, and the behaviors analyzed to reverse-engineer the real plaintext.
More advanced cipher modes incorporate a single-purpose message authentication feature into the encryption, which will cause decryption to fail in the same way with either a bad key or a corrupted ciphertext. CCM, which is Counter w/ CBC-MAC, is one of these modes; first, the message is "hashed" by running it through CBC encryption with the given key, but only keeping the last block of the ciphertext (remember that "chaining" of each previous ciphertext into the next block of plaintext, and the cascading error it causes? That's a beautiful way to calculated a "keyed hash" of the message). The message and its MAC are then encrypted again in Counter mode (related to CBC but slightly different; instead of the previous block of ciphertext, a nonce, produced by a combination of the IV and a sequential counter, is combined with each block of plaintext to "salt" it) to produce the ciphertext that is transmitted or persisted.
To decrypt, the message is decrypted in Counter mode with the key, then the message portion is hashed in CBC mode with the same key and compared to the decrypted MAC. If the MACs don't match, an error is given. Again, as used in a file encryption application, if there is an independent method of verifying that file integrity is good, the only other explanation is that the wrong key was used.
Continuing the aside, the beauty of this mode is that there's no way to turn it against itself as a padding oracle; if a ciphertext has been tampered with, or if it was decrypted with the wrong key, the MACs won't match up, and with that being the test for proper encryption (and thus the error given), decryption failure gives an attacker much less information (pretty much every attempt except one using the correct key and an untampered-with ciphertext will fail with exactly the same error every time). Another similar mode is Galois/Counter Mode or GCM, which has similar behavior but better performance and parallelization due to the use of a faster checksum calculation.