You should never silently ignore errors, because your program is built on a series of actions which implicitly depend on everything that's gone before them going right. If something goes wrong in step 3, and you try to continue on to step 4, step 4 is going to be starting out based on invalid assumptions, which makes it more likely that it will end up generating an error as well. (And if you ignore that too, then step 5 throws an error, and things start to snowball from there.)
The thing is, as the errors pile up, eventually you'll run into some error so big that you can't ignore it, because it will consist of something being given to the user, and that something will be completely wrong. Then you have users complaining at you about your program not working right, and you have to fix it. And if the "give something to the user" part is in step 28, and you have no idea that the original error that's causing all this mess was in step 3 because you ignored the error in step 3, you're going to have a heck of a time debugging the problem!
On the other hand, if that error in step 3 makes everything blow up in the user's face, and generates an error saying
SOMETHING WENT BADLY WRONG IN STEP 3! (or its technical equivalent, a stack trace,) then the result is the same--the user complaining at you about the program not working right--but this time you know exactly where to start looking when you go to fix it.
EDIT: In response to the comments, if something goes wrong that you anticipated and know how to handle, that's different. For example, in the event of receiving a malformed message, that's not a program error; that's "user provided bad input which failed validation." The appropriate response there is to tell the user that he's giving you invalid input, which is what it sounds like you're doing. No need to crash and generate a stack trace in a case like that.