JB Debugging method (Welcome to add)

In JBuilder9, you can use red dots in the editor to display code errors for the current line, but not to display logical errors and run errors, so you need to learn more about how to do error checking and debugging to troubleshoot logic and run-time errors. First, you want to set the breakpoint. method is very simple, and clicking the mouse in front of any line in the editor automatically sets the row to a breakpoint. The above breakpoint is just the simplest line breakpoint, but there are other types of breakpoints. There are 5 types of breakpoints:

Line is raised before code for the program-specific row is executed.

Exception is thrown when the code throws a specific exception

Class

Method is raised when it arrives at a way that is set to a breakpoint.

Cross-process

Different debuggers support different breakpoints. Some common types are: A line breakpoint is thrown before code in a program-specific line is executed. Method breakpoints are raised when a method that is set to a breakpoint is reached. A count breakpoint is thrown when a counter reaches or exceeds a particular value the exception breakpoint is thrown when the code throws a specific exception the store-change breakpoint is raised when the content being stored in a specific address range is modified when an address breakpoint is set to the point at which a breakpoint is made: Some debuggers are only in the compiled version of Java code ( Some breakpoint types are supported on the Just-in-time compiler-generated code (code generated using the Javac tool). An example is an address breakpoint. Each tool may be a little different in the way you can set breakpoints. Check the documentation for your tool.

The user can also access the debug interface of the program by selecting Debug in the Run menu and displaying the error files in blue with the Project menu item. When you debug and run the program, the system will display the error (the red part of the text), the name and the line of the program, click the section, in the editor will cut into the file, and highlight the error of the program line. When the user needs to observe the object, first add the Observation object by clicking the Add Watch menu item in the Run menu, locating the breakpoint on the object, and then running Debug project into debug state.

You might ask, how do I know where to place a breakpoint? If you have no sense of the problem at all, you can set a breakpoint at the beginning of the main () method if your code generates stack trace and sets breakpoints where the program produces it. You will see the line number of the source code in the stack replication. If your output or the specific part of the graphic display does not display the predefined information correctly (for example, the text field displays the wrong text), you can set breakpoints where the component is created. You can then step into your program to display the values associated with the GUI object. Experience will set breakpoints in the most appropriate place. You can set multiple breakpoints in a class or program.

The term that is frequently encountered when debugging a program is: Enter the execution current line. Executes the first line of the invoked method if the current row contains a method call. If the method in the class is compiled with an option without debugging information (that is, the-G option is not used), you will see the no source Available message. Stops while executing the current line without invoking a method or routine on the row. Returns the row that is executed from the current execution point and immediately returns to the calling current method.

Stack traces when a Java program makes a kernel dump (core dumps) it produces what we call stack trace in the console. Stack replication tells developers the exact path to a problem. It will describe the class and method names and the number of lines in the source code (if you compile with the debug option). If you start debugging and stopping at the beginning of a stack copy, you can look back at your code to see what actually the statement was executed. This is a quick way to find the procedure problem. You can also manually force a stack copy to be generated using one of the following methods. Throwable (). Printstacktrace () generates a stack copy at the point where the method is called. The replication will show the threads involved in the method call. Thread.currentThread.dumpStack () only produces a snapshot of the current thread. Use forced replication when you need to understand the conditions under which your program will generate stack replication. The following procedure is an example of a mandatory stack replication. This piece of the program is a file copy. We judged whether the copy was successful by comparing the length of two files to be equal. If not, we write a copy of the file and force the stack to print (see Bold declaration). Throwable () is a class in Java.lang, Printstacktrace () is a method of throwable () that prints the replication of the program execution path.

Diagnostic Methods The Java language provides methods to track your method calls to the JVM in the runtime () class. These traces will generate a list of each method invocation of your JVM bytecode. Note that this list can produce a lot of output, so use it in a small part of your code. Opening tracing can include the following line in your code: Tracemethodcalls (TRUE) turn off using: Tracemethodcalls (false) to open the JVM and observe its output to standard output.