Apex Debugger Tool Extensions VS-Code

 The Apex Debugger, commonly known as the Apex Interactive Debugger, is a conventional debugger that enables users to debug their Apex code in sandboxes and scratch orgs in real time while using Visual Studio Code as the client. 

You can employ it for: 

• Create breakpoints in the triggers and Apex classes. 
• View variables, such as collections, types from the Apex System, and sObject types. 
• View the call stack to see variables, triggers that Apex Data Manipulation Language (DML) has set off, and method-to-method calls. 
• Interact with the global classes, exceptions, and triggers of the managed packages you have installed. The variable inspection window only shows global variables when inspecting objects of managed types that aren’t visible to you. 
• Run to the breakpoint, step into, over, and out, and other conventional debugging techniques. 
• Your results should be output to the Debug Console. 

Establish Apex Debugger 

Follow these setup instructions before using Apex Debugger for the first time in Visual Studio Code. 

Note: To debug subscriber orgs, you can only use the default license given to License Management orgs with the ISV Customer Debugger. Use the Replay Debugger if you don’t have an Apex Debugger license. 

• For all varieties of scratch orgs that you intend to debug, add the DebugApex functionality to the definition files: 
• the feature “DebugApex”
• Run SFDX in VS Code: Make a default Scratch organization. 
• Select a file for the scratch org definition that has the DebugApex feature. 
• As soon as your scratch org is prepared, give the admin user of the org access to Apex Debugger. 

1.  Run SFDX: Open Default Org in VS Code. 
2. Enter Permission Sets in the Quick Find box in your browser’s Setup menu, then click Permission Sets. 
3. Select New. 
4. Give the permission set a memorable name, like “Debug Apex,” for example. 
5. Select None from the User License dropdown option in the section that asks “Select the type of users who will utilise this permission set.” You can give the permission set to various user types by selecting None. 
6. Save your edits. 
7. Please select System Permissions. 
8. Press Edit. 
9. Enable Apex Debug. The additional permissions needed by Debug Apex are immediately added. 
10. Save your edits. 
11. To manage assignments, click. 
12. Add Assignments by clicking. 
13. Click Assign after choosing the users to whom you wish to grant the permission set. 
14. Select “Done” 

• Optional: Run SFDX: Pull Source from Default Scratch Org in Visual Studio Code. Add your newly created permission set to your source control repository after that. Running sfdx force will allow you to grant permissions to scratch org users if you have a copy of the permission set in your Salesforce DX project. Your Perm Set Name user:permset:assign 
• Make an Apex Debugger launch configuration in Visual Studio Code. 

1. Click the bug icon in the VS Code Activity Bar to see the Debug view (hover text: Debug). 
2. Click the gear icon (hover text: Configure or Fix launch.json) and then choose Apex Debugger to create a launch.json file. (Clicking the gear symbol opens the file if you’ve already generated it.) 
3. Add a “Launch Apex Debugger” configuration to the “configurations” array. The bare minimum details it ought to have been: 

"configurations": [
  {
    "name": "Launch Apex Debugger",
    "type": "apex",
    "request": "launch",
    "sfdxProject": "${workspaceRoot}"
  }
]

4. Launch.json should be saved. Even if you work with many scratch orgs, each project only needs one launch.json file. This file is located in the.vscode directory for the project. 

Note: The Visual Studio Marketplace offers the unofficial debugger extension Salesforce Apex Debug. It is in opposition to our authorized extension. While utilizing ours, make sure that extension is disabled. 

Debug Your Code 

Open the column to the left of the line numbers in a.cls or.trigger file to set a line breakpoint. Red indicates active breakpoints. Breakpoints that aren’t in use are grey. A list of your breakpoints is displayed in the Debug view’s Breakpoints panel. 

Select Launch Apex Debugger from the configuration dropdown menu at the top of the Debug view to begin a debugging session. then press the green “play” button (hover text: Start Debugging). 

Any synchronous activity that executes a line of code with a breakpoint while a debugging session is active results in the breakpoint being reached. You can look at the call stack and your variables’ most recent values when execution is halted. Using the Debug actions window, which shows at the top of the editor when a debugging session is active, you may also step through your code and observe those values change. Up to two threads can be debugged simultaneously. To learn more, consult the Visual Studio Code documentation’s section on debugging. 

Establish Exception Breakpoints 

Set breakpoints on exceptions to force Apex Debugger to stop running when an error occurs while debugging. The debugger pauses on the line of code that generated the exception when an exception breakpoint is reached. The name of the exception is displayed in the Call Stack panel of the Debug view. 

Press Ctrl+Shift+P (Windows, Linux, or macOS) to access the Command Palette, then choose SFDX: Configure Apex Debug Exceptions to establish an exception breakpoint. The Apex classes in your project that implement Exception as well as the exceptions in the System namespace are included in the list of accessible exceptions. Select Always break after choosing an exception from the list. 

Run the SFDX: Configure Apex Debug Exceptions command to view your exception breakpoints. The exception classes with active breakpoints are displayed at the top of the list with the label “Always break.” Choose an exception from the list, then click Never break to remove the breakpoint. 

All of your exception breakpoints are deleted when VS Code is closed. However, your line breakpoints are still in place. 

Users and Request Types to Allowlist 

Create a permitted users list in your launch.json file to filter which requests are debugged. (The launch.json file is located in the.vscode directory for your project.) All events in your org cause debugging to start during a debugging session if you don’t use an approved users list. Create allowlist users or request types to narrow your attention to the events that are crucial to the issue you’re trying to solve. 

Add filters to the “Launch Apex Debugger” configuration: 

"configurations": [
  {
    "name": "Launch Apex Debugger",
    "type": "apex",
    "request": "launch",
    "sfdxProject": "${workspaceRoot}",
    "userIdFilter": [],
    "requestTypeFilter": [],
    "entryPointFilter": ""
  }
]

Press Ctrl+Space to have the “requestTypeFilter” auto-complete possible request type values. 

Enter a regular expression as the value for “entryPointFilter” to filter by entry point. Enter “.*/apex/MyPage.apexp” for instance to accept requests from the Visualforce page MyPage. 

Considerations 

When using Apex Debugger, keep in mind these restrictions and known difficulties. 

General Considerations 

• When you save your modifications after editing Apex classes while a debugging session is active, your breakpoints might not match the debugging output. 
• When you shut off Visual Studio Code before stopping your debugging session, it becomes orphaned. You cannot start a new session if you have an orphaned session. Run SFDX: Stop Apex Debugger Session in VS Code to end your current session. Go to Apex Debugger in Setup to control the Apex Debugger sessions for your Dev Hub. 
• There is no eval functionality available. 
• Hot switching is not allowed. Your debugging session is ended by these actions: 
• Putting or removing a package 
• Recompiling your org’s metadata after saving modifications 
• During a debugging session, the following objects cannot be saved with changes: 
• classes or triggers in apex 
• Visualforce components or pages 
• resources for lightning 
• Allowances or preferences 
• Customized objects or fields 

Entry Point Considerations 

The following entrance points are not accepted: 

• Code that runs asynchronously, including asynchronous tests 
• Tip: Synchronous code can execute in the space between two startTest and stopTest methods. Use these techniques in your tests to debug your asynchronous functionality. 
• Apex Inbound email code for batch, queue, and scheduled messages with the @future annotation 

Breakpoint Considerations 

• Conditional breakpoints cannot be set. 
• Breakpoints placed on a get or set method must be located inside the body of the method. 
• Execute Anonymous blocks cannot have breakpoints placed on them or be stepped through. However, we display your Execute Anonymous frame in the stack when you reach a breakpoint using Execute Anonymous. Click this line in the stack to see the variables in your Execute Anonymous code. 

Variable Considerations 

• Variables are not watchable. 
• Variable inspection is not supported in dynamic Visualforce and Lightning components. 
• The instance variables of objects from the Apex library are not drillable. Use the function toString() { [native code] } methods of these objects to view their contents. 
• A loop’s stated variables are accessible from outside the loop. 
• Drill into variables to view the values of their offspring. For instance, the results are nested as follows if you perform the query [SELECT Id, ContactId, Contact.accountId, Contact.Account.ownerId FROM Case]. 
• Even if you don’t explicitly SELECT the durableId variable while running a SOQL query for variables from the EntityDefinition table, it will still appear in your results. 

Case
–> Contact
—–> contactId
—–> Account
——–> accountId
——–> ownerId 

In conclusion, the Apex Debugger, also known as the Apex Interactive Debugger, is a valuable tool for Salesforce developers using Visual Studio Code. It allows developers to debug their Apex code in real-time, making it easier to identify and resolve issues in their code. Here are some key takeaways: 

• Key Features: The Apex Debugger offers essential debugging features such as setting breakpoints in triggers and Apex classes, viewing variables and call stacks, interacting with global classes and exceptions, and using traditional debugging techniques like stepping into, over, and out of code. 
• Setup: Setting up the Apex Debugger involves configuring your scratch orgs, granting permissions, and creating a launch configuration in Visual Studio Code. The setup ensures that you can effectively debug your code. 
• Exception Breakpoints: You can set breakpoints on exceptions to stop the debugger when errors occur. This helps pinpoint issues in your code related to exceptions and allows for quicker debugging. 
• User and Request Filters: You can create filters in the launch configuration to allowlist users or request types for debugging. This enables you to focus on specific events that are relevant to the issues you are trying to solve. 
• Considerations: It’s important to be aware of the limitations and known difficulties when using the Apex Debugger. For example, you should avoid making code changes during a debugging session, as it can lead to discrepancies with breakpoints. 

In summary, the Apex Debugger is a powerful tool for Salesforce developers that enhances the debugging process. By following the setup instructions and best practices, developers can streamline their debugging workflows and efficiently identify and fix issues in their Apex code.