While testing my delphi application, some Exceptions are raised but the debugger is not showing where (like it used to). Is there a setting which is causing this?
EDIT: When an exception occurs, a message appears alerting me to the fact that an error has occurred and what type of exception it is. Normally, I would be able to click 'break' and it would show me at which line the error had occurred, but when I click break, this doesn't happen.
It might help if you post a screen shot of what you actually do see before and after clicking Break.
And you haven't really answered the very first comment on your question: "What errors are occurring?" The point is if it's specific exceptions that aren't showing the code - they may be occurring in an external DLL.
As a first step check if Delphi will show the exception in the most simple case:
Drop a button on your form.
Write an OnClick handler with the following code: raise Exception.Create('This is a test');
NOTE Make sure you try this in both your existing app, and in a brand new stand-alone app.
If Delphi doesn't show you that exception in the simple app, I'd be very surprised, and some more serious digging will be required.
If it is shown in the simple app, but not in yours, then there's some specific problem in your project:
Ensure you aren't disabling debug info {$D-} or {$DEBUGINFO OFF} somewhere in your project.
You might have exception hooking code in your project that is somehow interfering. Try disabling exception loggers and similar tools to narrow down the problem. (Don't forget to re-enable the appropriate tools once the issue is resolved.)
Verify that your search and browsing paths are correctly configured to find the source code in order to show you the error.
If the simple exception is shown in both apps, then we'll probably need to know exactly what exceptions aren't showing to help further. However, here are a few more pointers (^s):
Go to Tools | Options. Under Debugger Options, look for Native OS Exceptions. Verify you haven't changed any of these settings.
When the exception occurs, open your Thread Viewer, and check if the the exception was raised on the main thread or another thread.
Also open your Call-stack Viewer, and verify you actually do have a call-stack.
Then check if Delphi will show the code for any of the call-stack lines.
NOTE There is still the possibility that Delphi is simply unable to find the source unit depending on where the exception is raised. However, Delphi is supposed to prompt you and ask where it can load the file from in such situations. (It definitely worked in older versions of Delphi.)
But I wouldn't rule it out because a buggy plugin might well be suppressing the prompt.
You can control the reaction of the debugger on exceptions from within the options.
Go to Tools\Options.
Click on the Debugger Options, then on language exceptions.
You probably have unchecked "Notify on language exceptions".
Else you can enable as much as possible.
Be sure to enable all debug information in your project:
Debug information
Symbol reference info
And try without optimizing.
Related
I'm wanting to determine at run-time if an exception class has been specifically ignored in the IDE. The reason is this: When running an application from the IDE I might receive an exception that I know the reason for, but don't want to deal with right now. So I check the "Ignore these exceptions" box and click continue.
Its possible that I might forget to disable this setting later, so I want to add code at the startup of the application to warn me that exceptions in the list at Tools/Options/Debugger Options/CodeGear Debuggers/Language Exceptions are being ignored.
An alternative would be a fragment of code that could determine the status of an exception class (i.e. whether ignored or not) without triggering the exception in the IDE.
If you don't want to deal with exceptions in the IDE set breakpoints around the point where they occur. Then edit the breakpoints:
For the first one set its advanced properties to not Break on exception and to Ignore subsequent exceptions.
For the second one set its advanced properties to not Break on exception and to Handle subsequent exceptions.
You have to take care to not throw away those breakpoints (e.g. using Delete all breakpoints), and occassionally they lose their proper place in the editor. It's also difficult to share these with other developers if you work with source control.
The application being debugged doesn't have access to the debugger's list of ignored exceptions. Unless you figure out where and how the debugger stores that configuration and read/decypher it manually.
I have seen other questions with this same problem on XE Forums, but still no answer. I run my application from with the XE IDE and I get an EOleSysError - 'The system cannot find the path specified'.
But, I can go out to explorer to the same directory and run that same app outside the IDE and it runs fine. No errors. All of my assemblies are located in the build directory of the application, so I'm not relying on GAC or anything, just directory the executable is in.
Is this a known bug with XE and Windows 7 x64?
Is this a path problem? Environment variable issue? It almost seems like the IDE is running my exe from another directory, but the exe is only being compiled in one place.
Any help here would be appreciated.
Thanks,
Rick
It's not a bug at all. The debugger is catching the exception, and letting you know about it before it passes it to the exception handler in the code. It's working by design, letting the developer know that the exception happened.
If you want to avoid this happening, you can do one of a few things:
(Easiest) Set a breakpoint on the line immediately before the exception is raised. Right-click the line, and choose Breakpoint properties from the context menu. Click the Advanced... button, and then uncheck the Break checkbox, and check the Ignore subsequent exceptions checkbox, and then click OK to close the dialog. Set a breakpoint on the line after the exception is raised, and repeat the process above, except this time check the Handle subsequent exceptions checkbox. I say this is easiest because you can disable it to break on the exception simply by disabling the breakpoints, and remove it entirely by just removing the breakpoints, and you get a visual indicator that something is different for that block of code.
Disable IDE error handling for all EOleSysError exceptions, from the Tools->Options menu, find Debugger Options->CodeGear/Embarcadero Debuggers->Language Exceptions, and add EOleSysError to the Exception types to ignore dialog, and make sure the item is checked. It's the way Indy's exceptions are prevented from stopping the debugger, for instance.
Just click the Continue button in the exception dialog, and let the code keep running. This gets a little annoying sometimes, such as when you're running code in a loop, and something in the loop is raising the exception; you keep getting the dialog over and over again.
When I open a form, I am suddenly getting an error message:
"Error reading form: 'X' "
Cache is not initialised. Must call TCache.Initialise first. Ignore the Error and continue? NOTE: Ignoring the error may cause components to be deleted or property values lost"
The "Cache is not initialised" bit is an exception raised by one of our classes.
My first question is, why is the Delphi IDE running my code without me asking it to "Run Program"? What code does it run? Is there any way to turn this off?
Secondly, is there any way I can trap this error in the debugger, so I can work out where in the call stack this exception occurs? I have tried putting a breakpoint where the exception is thrown, but Delphi ignores it.
And also, once I have worked out where this exception is coming from, is there a way to tell when I am in "design mode" and not run that code, or run different code? Or even better, not run that code at all if in design mode?
[Update: See Francois' answer to how to stop code running in design mode.]
You have some component code that you wrote that is executed when the IDE is trying to load the dfm.
You can test in your code if your component is in "design mode" with
if (csDesigning in ComponentState) then
When the IDE loads a DFM, it creates live objects within the Form Designer, which means component run-time code is actually run within the IDE. As such, component code needs to check the TComponent.ComponentState property for the csDesigning flag if it wants to skip running portions of its code at design-time.
I'm modifying our VCL components so the end user's application links to our dcu files, instead of building our source code each time. We have everything working, but I want the debugger to stop on the user's code when an exception is raised. At first it would stop in our dcu and open the CPU window. I was able to prevent that by removing debug info from the dcu files. But now it still doesn't stop in the users code (like DevExpress libraries and others do).
The following screencast is a short example. The first time I cause an exception in the DevExpress code, and the debugger correctly stops in my button event. The second time I cause an exception in my components, but the debugger doesn't have my button event on the call stack, and doesn't show me where the problem was. Any ideas why?
http://screencast.com/t/NjhlOTRk
Currently building the DCU's with these options:
-$W+ -$D- -h -w -q
Update: The TDataSet methods in between my component and the button event seem to cause this behavior. If I instead call a direct method of my table, I get the expected behavior. I'm guessing there isn't anything I can do about this, but I'm still curious why it happens.
If the sourcecode is build instead of dcu's, there is something wrong in the configuration.
The dcus should be in the search path, the source in the browse path.
This way it is not possible for the compiler to not use the DCUs, and you can still debug.
Have you tried setting/unsetting:
Project Options -> Delphi Compiler -> Compiling -> 'Use debug .dcus' (in the Debugging subsection)
I opened a project (created in D2007/08) in D2009 and it would compile but throw tons of exceptions when executed. Strange thing, but I know the project's a mess, so I want to go ahead and fix it. Well, not really fix all of it, just make it work would be enough.
When I ran it, I got some Debugger Exception Notification (the little message dialogue with Break, Continue, Help buttons) and I wanted to proceed and see if would perhaps work when skip over the exception. I checked the little "Ignore this exception type" check box in the bottom left corner and clicked Continue. Now I no longer get the Exception Notification, but the application still doesn't run. I just get a couple of vague error boxes and have very little idea what's going on.
I would like to re-enable the exception type I previously selected to be ignored. But I can't find the option anywhere. Where should I look for this? Can anyone help?
I have found the ignored exception types in
(Main menu) Tools >> Options >> Debugger Options >> CodeGear Debuggers >> Language Exceptions >> and there is the list of exception types ignored.
It's somewhat more hidden than in D2005 but very close to what was said in the article referenced by Stuart Dunkeld.
The following is extracted from this page on the Delphi Q&A by Rob Kennedy: (CC licensed) although it relates to Delphi 2005 it may help.
Why do I continue getting error messages even after I have written an exception handler?
In its default settings, the Delphi IDE notifies you whenever an exception occurs in your program, as in Figure 1. 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.
Avoiding notification
If you do not want to be notified when an exception occurs, you have a few options.
You can use Delphi’s “advanced breakpoints” to disable exception handling around a region of code. To begin, set a breakpoint on the line of code where you want the IDE to ignore exceptions. Right-click on the breakpoint dot in the gutter and open the breakpoint-property dialog. In the advanced section are some check boxes. (See Figure 2.) Clear the “Break” box to prevent the debugger from interrupting your program at that line, and set the “Ignore subsequent exceptions” box.
Afterward, set another breakpoint where you want the debugger to resume handling exceptions. Change its properties to handle subsequent exceptions.
You can tell the debugger to ignore certain kinds of exceptions. Figure 3 shows Delphi’s language-exception options. Add an exception class to the list, and all exceptions of that type and of any descendant types will pass through to your program without Delphi interfering.
In an option related to the previous one, you can tell the debugger not to interrupt on any exceptions. To do that, clear the “Notify on language exceptions” check box.
Finally, you can turn off integrated debugging altogether. Delphi will not notify you of exceptions, and it will also not stop at breakpoints or allow use of the “Pause” button. Turn off integrated debugging in the debugger options, as shown in Figure 5 for Delphi 2005.