In case of encrypted text I commonly see "magic" footer being used as a sole verification method for AES CBC; i.e. assumption is that, if last bytes were decrypted correctly, all previously decrypted bytes are valid too. However, that assumption can fail horribly.
Once case when it fails is when configurable IV is used. You can have nonsense for a IV vector and decryption will succeed. Even worse, while first few bytes will be invalid, 8-byte blocks following it will look just fine. If you validate content only by last few bytes, your program might happily continue to work without any issue.
But lets assume you have static IV and that this issue doesn't affect you. And you are worried only about stream errors anyhow. Well, I hate to inform you but CBC mode is self-synchronizing, i.e. any recoverable errors in one block will go away after certain number of blocks. For example, if you have an error in first byte of a stream, next fifteen bytes will be corrupted but rest of stream (including your footer) will look just fine.
Corruption in the middle of stream will cause exception most of the time, but not always. If it passes unnoticed you can have valid header, valid footer and garbage in between.
As you can see from the two examples above, you cannot rely purely on fact that some stream bytes were decrypted as a proof that some other part of stream is not corrupted. Only way to be sure about stream validity is to use hash/CRC functions that were actually designed to detect corruption.
Example of both these behaviors is available for download. Below is example output with both valid and invalid decryption having a same footer (FF-FF-FF-FF):
Decrypted (OK) ..........: 00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-FF-FF-FF-FF
Decrypted (invalid IV) ..: FF-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F-10-11-12-13-FF-FF-FF-FF
Decrypted (invalid input): 31-33-7C-D9-A9-91-47-DD-52-3A-64-08-FD-2F-D4-C8-1D-11-12-13-FF-FF-FF-FF