Depends on your program, the needs of said program, and the critical level of said program.
Slightly Longer Answer
A good "shotgun-catch-all" solution is to see if your program's coding language has some kind of default error handling method or class that ALL errors pass through and just override it to catch the error, log it/report it to the developer, and then kill the program.
If you develop your program in some fashions (i.e. isolated and encapsulated modules) you can, theoretically (because it is dangerous to keep going if any error is found), reset that module and keep going/retry on that module.
The biggest drawback to this is that you are hoping the problem section (whatever that may be) will fix itself after umpteen iterations of it. It is almost like accepting insanity as a solution (keep trying expecting a different result)...but for some programs, that MUST be done because they are so mission critical (think of programs used in medical situations...they CANNOT fail and must keep going no matter what).
Keep in mind, the "accept insanity" solution can also present the user with a never ending program (i.e. they cannot proceed or the computer gets stuck in a loop trying to fix the program).
It is a double edged sword, yes you can design the program to keep going and reset the problem section and that has the potential of introducing errors later on because of corrupt data and making the end user "repeat" the process until fixed.
On the other hand, killing the program for every error can make your program seem unstable or poorly designed even if it is the user's fault for making the program crash (i.e. the art of user input validation) or can cause the developer to start getting lazy with bug fixes (because they get bombarded) by using things like try-catch blocks everywhere (I saw this on a project one time...almost every method was try-catch'ed).
Like my first line, it really depends on your program.