If behavior changes inside and outside the debugger, then it’s not really your program that’s telling you about exceptions. I’ve written about this phenomenon on my Web site:
Why do I continue getting error messages even after I have written an exception handler?
An excerpt:
In its default settings, the Delphi IDE notifies you whenever an exception occurs in your program … . What’s important to realize is that at that point, none of your program’s exception-handling code has run yet. It’s all Delphi itself; its special status as a debugger allows it to get first notification of any exception in your program, even before your program knows about it.
After you dismiss Delphi’s message box, execution will be paused at the best line of your source code Delphi could find to represent the source of the exception. Press the “Run” button to have your program resume. Control will pass to the next finally or except
block. Before you resume your program, you may use the various debugging tools at your disposal. You can inspect the values of any variables in scope, and you can even modify their values.
So, how do you notify Delphi that you’ve already handled an exception? You don’t — because your program hasn’t handled it yet. And why can’t the debugger detect whether your program is going to handle an exception? Because in order to do that, it needs to execute your program further. Detecting the lack of an exception handler is like solving the halting problem. The only way to determine whether an exception is going to be handled is to let the program run and then see whether the exception gets handled. But by that point, it’s too late to do any debugging, so the debugger has no choice but to pause your program when it first detects an exception and then let you figure out what to do from there.
My article goes on to describe some ways you can avoid having the debugger catch certain exceptions, summarized here:
- Use advanced breakpoints to temporarily disable breaking on exceptions for certain regions of the code.
- Configure the debugger to ignore certain classes of exceptions (and their descendants).
- Tell the debugger not to notify you about any exceptions.
- Disable integrated debugging altogether.
There’s another options that I didn’t include in my article:
- Change your program such that the exception doesn’t get raised in the first place.
You say you’re validating numeric input. That sounds to me like you’re doing something like calling StrToInt and then catching the EConvertError exception when the input isn’t a valid integer. That’s an expensive way of validating input. Instead of that, use TryStrToInt, which will tell you whether the conversion succeeded, or StrToIntDef, which will silently return a default value instead of raising an exception. Another option is plain old Val, which tries to convert a string, and if it fails, it tells you which position in the string caused the failure. Val is particularly useful if you want to consume as many characters as possible for the conversion and then resume parsing at the next non-numeric character.