I’ll start with the first option. Break on all errors simply disables your error handlers. This is useful when you are attempting to debug after you’ve put in error handlers, because you can have errors in the handlers themselves, or you can lose track of where the error happened when the error bubbles up the containership heirarchy (errors that aren’t handled in a procedure attempt to find a handler in a calling procedure, which can be confusing if you’re trying to find the offending line of code).
Next, break on unhandled errors doesn’t actually break in a class module if there is a line of code causing an error in there. If you have this option set, and you call a method in a class, and there’s an error in the line of code in the method, you’ll break on the line in your client that has the method call.
Break in class module goes to the line of code in the class that has the error. A caveat to this is that if you are working with an ActiveX EXE, the controlling setting is in its project rather than in the client project. That is, you can have break on all errors set in your client project, and break on unhandled errors set in your ActiveX EXE project, and you won’t break in the class module because you are working with two separate processes.
I prefer personally to leave it set on break in class module, because it lets me drill down to the site of the error with greatest precision. This is before I start doing error handlers, though; at that point I generally bounce around all three, depending on what I’m trying to stabilize.
Finally, I do NOT recommend EVER using On Error Resume Next except in the context of inline error handling.