Error Handling and Debugging
leJOS NXJ provides several features for error handling and debugging, including:
The Remote Monitoring and Tracing facility, which is described in its own section below, can also be used for debugging.
Most of the standard Java language exception classes are supported by leJOS, and user can create their own exception classes.
The following ExceptionTest example demonstrates what happens for an exception that is not caught – in this case an ArrayIndexOutOfBounds exception.
When this code is run the NXT will display the uncaught exception screen. Which looks something like this:
But what are these numbers telling us? The first line tells us the number of the exception class that has been thrown, in this case class 28. The following lines show us a mini stack trace, one for each method in the call stack, showing the method number and the program counter location within the method. The top most item is the location that the exception was thrown, which in this case was at location 11 in method number 20.
So we now understand what the numbers are, but how do we relate them to our program? Well one way is to use the verbose output from the linker, an abbreviated version of which looks like this:
We can use the class table to look up the exception class, in this case class 28 is java.lang.ArrayIndexOutOfBoundsException so we know we have an array out of bounds exception. Now we can look up the method names. Method 20 is ExceptionTest.m1, method 21 is ExceptionTest.m2 and method 22 is ExceptionTest.main. Which tells us that the exception has been thrown in method m1, that was called from method m2, that was in turn called from method main. So far so good, but how do we use the value of the location counter to narrow down where exactly the exception occurred. Well we could decompile the byte code classes and use that but there has to be an easier way right? Well yes there is. leJOS comes with two tools that make this process much easier, one helps you decode the above numbers, the other will do all of the work for you. Both tools require an additional linker option -od which tells the linker to output extra debug information to the specified file. Once we have this file we can use the NXJDebugTool to decode the exception data as shown below:
Which as you can see tells you exactly which line in the source code the exception was thrown on.
The final option is to make use of the leJOS remote console application (see below for more details). again we need some extra linker options, this time -od to create the debug information and -gr to add the remote console debug code to the program. If we link with these options and run the program again, then three extra things happen, first the program will wait for the remote console application to connect to it, secondly any output that uses the System.out stream will be re-directed to the console display (in this case "Running") and finally the exception information will be displayed by the remote console in an easy to understand form. See below for an example of this:
If the leJOS firmware crashes you will normally a Data Abort. The screen shows the PC value where the failure occurred, and other details of the failure.
The screen is something like:
The most common reason for data aborts is executing a file that is not a leJOS NXJ binary, or executing an incomplete leJOS NXJ file.
If you get a data abort in any other case, you should report the error to the leJOS development team by posting the details on the leJOS NXJ forums.Back to top
You can use your PC as a remote console to display tracing statements generated your NXJ program. The lejos.nxt.comm.RConsole class has methods to it. Since there are no instances of this class, all methods are static.
To start debugging, you use one of these methods:
The NXT displays
and waits for the PC based monitor to connect.
Then execute the nxjconsole program on your PC. When the connection is
established, the NXT displays
If you use the variant of open with a timeout, it waits the specified number of seconds and if the debug monitor has not connected, proceeds without debugging. If the timeout is zero, it waits indefinitely.
You can also use the ConsoleViewer application to display the output.
Debug statements can be output using one of the methods:
If no successful open statement has been executed, the debug output is discarded. If there was a successful output, the string appears on standard out in the window or terminal that nxjconsole was run from, on the PC.
When debugging is completed, you should call:
This closes the USB or Bluetooth connection.