The debugger breaks on an exception (by default) based upon the rules of exception handling defined by the system. When an exception first occurs (first chance exception) then the debugger may or may not break in depending upon your exception settings. Most of the time we don't have that set because it would cause too many interruptions. If you resume from that exception (or you didn't configure it to stop) then the debugger continues and if the exception isn't handled you get the second chance (second chance exception). At this point your app is going to terminate and the debugger is giving you one last chance to look at the exception before your app goes away. If you resume from this your app terminates and the debugger will exit. The debugger settings have changed over the years but the overall behavior is the same. More importantly the debugger now allows you to adjust the behavior based upon the module it is coming from. For example you probably don't want to ignore exceptions in your code but you are fine not getting notified about handled exceptions in system code.
The first question I have is whether the exception is a first chance or second chance exception. In other words do you have a try-catch around the code that is ultimately failing and therefore your app is trying to handle it. If that is the case then the debugger is currently configured to break on a thrown exception. In the exception settings that appears when this happens is an option to ignore throwing that exception completely or in the current module. If, however, you don't have a try-catch then this is a second chance and the debugger should always break. Your app is going away so running the debugger again will terminate it.
Going back to your specific scenario it seems like your code should already have a try-catch around the call that may fail. The catch block will handle it so if you set a breakpoint inside there then when it catches the exception you can then drag the IP (the yellow arrow) back to the call that failed so it'll try to run it again.
I should also point out that some debugger settings are new and may impact the behavior. This includes whether you have enabled the Just My Code option, whether the exception is occurring in a separate process and you have enabled the option to break across boundaries, etc.