Difference between revisions of "Java Debugging Tips"

From AgileApps Support Wiki
imported>Aeric
imported>Aeric
Line 19: Line 19:


===Invoking Methods===
===Invoking Methods===
The [[Unit Test Framework]] is great for automated testing of Java methods, but note that database changes don't persist. That's a highly desirable feature in a test harness, but it means you can't run a test and then look for changes interactively, in the GUI.
The [[Unit Test Framework]] is great for automated testing of Java methods, but note that ''database changes don't persist''. That's a highly desirable feature in a test harness, but it means you can't run a test and then look for changes interactively, in the GUI.


To view changes interactively, the code can be launched by [[Rule]]. For example, use an [[Event Rule]] that runs when a record is added. (As a precaution, you can set up a condition so that the rule is triggered only when some flag is set.)
To view changes interactively, the code can be launched by a [[Rule]]. For example, use an [[Event Rule]] that runs when a record is added or updated. (As a precaution, you can set up a condition so that the rule is triggered only when some flag is set.)


=== Setting up a "Debug Mode" ===
=== Setting up a "Debug Mode" ===

Revision as of 20:28, 12 November 2013

Debug Messages

To debug a Java class:

  • Add messages to the debug log using
Logger.info("message text", "message type");
(The message type can be used for searching, when needed.)
  • Open the debug log in a separate page:
  • Go to GearIcon.png > Developer Resources > Debug Log
  • After running the code, refresh the page by clicking Debug Log in the sidebar.
  • Display a note at the top of the user's page:
Functions.showMessage("message text");
  • Abort processing and display an error message:
Functions.throwException("message text");
Learn more:

Invoking Methods

The Unit Test Framework is great for automated testing of Java methods, but note that database changes don't persist. That's a highly desirable feature in a test harness, but it means you can't run a test and then look for changes interactively, in the GUI.

To view changes interactively, the code can be launched by a Rule. For example, use an Event Rule that runs when a record is added or updated. (As a precaution, you can set up a condition so that the rule is triggered only when some flag is set.)

Setting up a "Debug Mode"

To ensure that your rule fires only when you are actively debugging, you can add a "Debug" flag to the User object, set the default to false, and then set it to true for yourself. The condition add-record Rule condition can then test for Owner.Debug equals true.

Or, more simply, change the value of your title field to "Developer", and then set the Rule condition to Owner.Title equals Developer. Anyone who creates a record is automatically its owner, so anyone who has the title "Developer" will execute the method when they add a record.