I think I'd approach this from the other direction. It might be good design to have a system that can recover from bus errors, but unless there's some specific design feature that makes errors inevitable (eg. long cables that pick up noise, or multiple asynchronous masters that might clash), you should expect I2C to be error free.
Instead I'd concentrate on trying to generate a trigger condition for your scope in the event of an error. Put some debug into your code which says something along the lines of "if the value read over I2C is out of range, then pulse this GPIO", then set your scope to record the I2C interface and trigger off that pulse.
It might then show you something unexpected that's happening on 'bad' accesses - maybe a particularly slow clock edge or an invalid logic level. Or you might discover that the transaction is perfectly OK and the bug is in the CPU after all (eg. an unfortunately timed interrupt). Maybe the slave device you're accessing reports garbage if it's read at exactly the wrong time (eg. when an update is taking place).