If I understand you correctly then the process you're describing happens on a couple of levels (or layers).
If the switch detects a checksum failure then it'll discard the frame and probably make an internal note of the error (Cisco 3550s certainly record errors, runt frames etc). At this point the switch couldn't know if the address was 'wrong' or which part of the frame was damaged so discarding it is the only reasonable thing to do. The checksum is just a way of deciding if "an error of some sort" happened when transmitting the frame, but can't tell you where in the frame the error was.
Now, that frame is part of a packet being sent somewhere. Because it gets dropped, the packet it belongs to is going to be broken and TCP is going to be patiently waiting for a packet with a particular sequence number to arrive. Part of the packet will arrive but the networking stack on the destination can't do anything with a part packet so will send a request to the source host asking for the whole packet to be resent.
In reality you could have some freak error in the part of the frame that holds the Frame Check Sequence. In this case the real data might be intact but the frame is dropped because it'd be checked with an incorrect FCS.
The destination knows which packet to request because it's kept a record of where it's gotten to in the sequence. If it receives packets 1,2,3 and 5, it'll know something went wrong with packet 'number' 4.
The different modes you talk of are Store and Forward, Cut Through and Fragment Free, which offer different levels of checking a frame before passing it onto the next device.
A hub would be oblivious to all the above since it's only concerned with bits - a hub literally just repeats everything it receives. In one ear and out the others, if you will.