Apex Debugger Considerations

Don’t be surprised if you encounter these potential “gotchas” when using the Apex Debugger.

Force.com IDE is in a maintenance-only state. We still provide support for the product through our official channels, but updates prior to October 12, 2019 will be only for critical security issues that arise. On October 12, 2019, we will no longer provide support or updates of any kind for Force.com IDE. On that date, we will also begin archiving documentation and removing download links for the product. We recommend that you start migrating to Salesforce Extensions for Visual Studio Code or one of the great tools made by our partners. For more information, see The Future of Salesforce IDEs on the Salesforce Developers Blog.

Warning

If you edit Apex classes while a debugging session is in progress, your breakpoints might not match your debugging output after you save your changes.
Your debugging session is orphaned when you close Eclipse before stopping your session. If you have an orphaned session, you can’t start a new session.
Eval functionality isn’t available.
Hot swapping isn’t permitted. These actions kill your debugging session.
- Installing or uninstalling a package
- Saving changes that cause your org’s metadata to recompile
  You can’t save changes to these items during a debugging session.
  - Apex classes or triggers
  - Visualforce pages or components
  - Lightning resources
  - Permissions or preferences
  - Custom fields or custom objects
These entry points aren’t supported.
- Asynchronously executed code, including asynchronous tests
  Test code between a pair of startTest and stopTest methods can run synchronously. To debug your asynchronous functionality, use these methods within your tests.
  Note
- Batch, Queueable, and Scheduled Apex
- Inbound email
- Code with the @future annotation
Keep these things in mind when working with breakpoints.
- You can’t set conditional breakpoints.
- Breakpoints set on a get or set method must be within the method’s body.
- You can’t set breakpoints in or step through Execute Anonymous blocks. However, when you hit a breakpoint using Execute Anonymous, we show your Execute Anonymous frame in the stack. To view your Execute Anonymous code’s variables, click this line in the stack.
Keep these things in mind when working with variables.
- You can’t watch variables.
- Variable inspection in dynamic Visualforce and Lightning components isn’t supported.
- You can’t drill into the instance variables of Apex library objects. To view these objects’ contents, use their toString methods.
- Variables declared within a loop are visible outside of the loop.
- Drill into variables to see their children’s values. For example, if you run the query [SELECT Id, ContactId, Contact.accountId, Contact.Account.ownerId FROM Case], your results are nested as follows.
  1Case 2--> Contact 3-----> contactId 4-----> Account 5--------> accountId 6--------> ownerId
- When you perform a SOQL query for variables from the EntityDefinition table, your results include the durableId even if you don’t explicitly SELECT that variable.

Force.com IDE Developer Guide

Apex Debugger Considerations

See Also