This has bitten me many times, and probably thousands of others: You don't run into fsck until something goes horribly wrong (unrecoverable bad sector); then when you do, you're prompted with the block number and the option to "ignore" (continue) or not (abort). Then when you continue, you have the option to attempt a rewrite...
...at which point a casual user may cross his fingers and say 'yes', hoping that block contains nothing important, only to realize belatedly (if ever) that `debugfs` exists and could've provided that information.*
Is it too much to ask that some small reminder of debugfs's existence be included in the warning, i.e.:
Error reading block 123456 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan.
Ignore error? yes
*** To examine this error, use debugfs before rewriting
Force rewrite? yes
... While I arrived long after the ext2 era, I see that ext2's fsck used to provide the associated filename immediately if it could. It appears that ext3 and ext4 fscks have always been less verbose. If it's still trying to report that information but can't retrieve anything useful due to the data loss and intrinsic designs of the filesystem, it would help equally to be more clear that the data is long gone, debugfs won't find anything either, and there's nothing to lose by trying the rewrite to at least force the disk to reallocate the sector somewhere clean.
[Obviously my conception of ext3/ext4 internals leaves something to be desired; the experience inspiring this request was with an ext4 filesystem on a disk suffering catastrophic failure.]