Tired of always having Delphi’s integrated debugger load when an exception is raised? It doesn't have to be that way, and this article shows you how in Delphi 7, Delphi 8, and Kylix.
By default, when an exception is encountered by an application that you are running from the Delphi IDE (integrated development environment), several things happen. First, your program stops executing. Second, the integrated debugger loads and details about the exception are displayed in a dialog box.
It takes two or more steps in order to resume your program's execution. First, you must acknowledge the exception by closing the displayed dialog box. Next, you must press F9 or click the run button to resume the execution of your application. Third, you must close the subsequent dialog box that displays the exception to the end user, which in this case is you. (This third dialog box is not displayed if the exception was a silent exception or if the exception was caught and handled in an except block.)
Tired of always having Delphi integrated debugger load when an exception is raised?
While this behavior is often welcome, there are times when I would prefer that the integrated debugger did not load. Instead, I would prefer to simply see the exception as the end user would see it, reducing the number of steps that it takes to continue testing the application.
For example, imagine that you are testing a database application, and that you raise an exception from a ClientDataSet's BeforePost method when your code determines that the record being posted is invalid. While testing the application, I would prefer to only see the error message describing to the end user why the record is being rejected without having the integrated debugger getting involved.
Here is another example. Imagine that you are writing an application using an Internet Direct (Indy) TIdTCPClient component to retrieve HTML from a Web site for parsing. With that component, you continue to call Read until it raises an exception, which signals that the page has finished downloading and the connection has been closed by the server.
Having the integrated debugger load when this exception occurs is nothing more than a nuisance. The exception is not really an error. It's really just a signal to your program. And by default, even if you are reading from the TIdTCPClient within a try-except clause, your application will still stop and the integrated debugger will load.
There are three ways to prevent the debugger from loading every time an exception occurs. The first is to disable the debugger altogether. You do this by unchecking the Integrated debugging check box on the Debugger Options dialog box in Delphi 7 and Kylix. Display this dialog box, shown in figure 1, by selecting Tools | Debugger Options.
Fig. 1
In Delphi 8, this checkbox is on the Options dialog box when the Debugger Options node is selected, as shown in figure 2. Display the Options dialog box by selecting Tools | Options from Delphi 8's main menu.
Fig. 2
This approach is overkill, though. Breakpoints do not work when the integrated debugger is not enabled. Similarly, the various Debugger windows, such as the Modules, Watches, or the Event Log are inactive when the Integrated Debugger is disabled. Consequently, I generally do not use this approach.
The second technique is to configure the debugger to ignore exceptions. There are two ways to do this. In Delphi 7 and Kylix, the easiest is to view the Debugger Options dialog box, select the Language Exceptions tab, and uncheck the Stop on Delphi Exceptions check box, shown in figure 3. Now, breakpoints will load the integrated debugger, but exceptions will not. Furthermore, Debugger windows will continue to be available.
Fig. 3
In Delphi 8, select the Language Exceptions node from the Options dialog box, as shown in figure 4.
Fig. 4
To resume the default behavior, simply check the Stop on Delphi Exceptions check box once again.
The second way to disable the integrated debugger from loading in response to an exception is to use breakpoints. I discussed this technique in the article "Using Non-Breaking Breakpoints in Delphi," which is published here on the Borland Developer Network. Consequently, I will not repeat that information again in this article.
The third technique is to tell the integrated debugger to ignore all exceptions of a particular class or group of classes. This technique also involves the Language Exceptions tab of the Debugger Options dialog box in Delphi 7 and Kylix, and the Language Exceptions node from the Options dialog box in Delphi 8.
Tell the integrated debugger to ignore all exceptions of a particular class or group of classes
Here's how you do it. Leave Stop on Delphi Exceptions checked (as well as Integrated debugging). Click the Add button on the Language Exceptions pane and add the name of the exception class that you want the integrated debugger to ignore.
When an exception is raised, the integrated debugger will check to see if the raised exception is an instance of one of the classes whose names appear checked in the Exception Types to Ignore list. If the exception is one of these classes, or descends from one of these classes, the integrated debugger is not loaded.
If at some later time you do want the integrated debugger to load when a listed exception is raised, either uncheck the check box next to the exception's class name in the Exception Types to Ignore list, or select the exception class name and click the Remove button.