Java > Debug
preference page.
The following preferences can be set using the
Java > Debug
preference page.
These options apply to java specific debuggers and have to do with suspending options and hot code replace.
|
Option |
Description |
Default |
|---|---|---|
| Suspend execution on uncaught exceptions |
This option controls if a program will suspend if an uncaught
exception is thrown.
For example if you try to call a method on a null object and a NullPointerException is thrown, with this option on your program will suspend at the location the exception was thrown |
On |
| Suspend execution on compilation errors | This option controls if a program will suspend when a compilation error is encountered | On |
| Suspend for breakpoints during evaluations | This option controls if breakpoints will suspend during an evaluation of code containing a breakpoint. For more information about evaluations go here | On |
| Open popup when suspended on exception | This option controls if a popup window will be displayed when execution of a program stops on an exception. The exception the program suspended on is made available for inspection in the popup | Off |
| Default suspend policy for new breakpoints | This option allows the default suspend policy to be set for new breakpoints. The suspend policy is used by breakpoints to tell the VM what to suspend, in this case either the thread the breakpoint is active in or the entire running VM | Suspend Thread |
| Default suspend policy for new watchpoints | This option allows the default suspend policy to be set for new watchpoints. The suspend policy is used by watchpoints to tell the VM what kind of field actions to suspend on - in this case either access and modification (both), access only or modification only | Suspend Thread |
| Enable hot code replace | This option controls if hot code replacement will be supported | On |
| Show error when hot code replace fails | This option controls if you will be presented with an error dialog when a hot code replace fails | On |
| Show error when hot code replace is not supported | This option controls if you will be presented with an error dialog when hot code replace is not supported. This can happen after you have made and saved changes to currently running code. | On |
| Show error when obsolete methods remain after hot code replace | This option controls if you will be presented with an error dialog when a hot code replace completed, but there were obsolete methods left over | On |
| Replace class files containing compilation errors | This option controls is class files containing compilation errors will be replaced | On |
| Debugger timeout | This option describes the length of time (in milliseconds) the debugger will wait trying to communicate with a running VM before giving up and disconnecting | 3000 |
| Launch timeout | This option describes the length of time (in milliseconds) that a launch will wait to complete the launching process before giving up and terminating. This option has no bearing on the length of time a program will run, only how long the process of trying to run a program will wait | 20000 |
| Warn when unable to install breakpoint due to missing line number attributes | This option controls if you will be notified when you try to set a line breakpoint on a line that has invalid line information | On |
| Prompt for confirmation when deleting a conditional breakpoint from editor | This option controls if you should be asked whether you really want to remove a breakpoint with a condition from the editor | On |
| Do not install breakpoints from unrelated projects |
Multiple versions of the same Java type can be available in a workspace, and each version can
have breakpoints configured at different source locations. When debugging, JDT tries to
determine the "right" set of breakpoints to install in the target VM. This analysis
now uses Java project dependencies by default.
To always install all enabled breakpoints, you can disable this option. Note that not all projects use explicit Java project dependencies. E.g. OSGi bundles typically use a dynamically computed classpath where project dependencies are computed by PDE. |
On |
| Only include exported classpath entries when launching | This option controls if only classpath entries marked as exported should be included in the classpath used for launching | Off |
| Use advanced source lookup | This option controls if the debugger will use advanced source lookup implementation in addition to standard source lookup heuristics. Advanced source lookup is a reliable source lookup when multiple versions of the same Java type are present in the target application and when Java types loaded by the application are not fully known in advance. It also enables on-demand sources download by JDT-based tools like M2E (on demand sources download requires explicit support by the tool). Advanced source lookup is only available for applications running locally. | On |