B4J Tutorial [B4X] ErrorAnalyzer -Turn Error Logs Into a Call History with Actual B4X Source Line Numbers and Text

Recently I have been looking at #Macros, and then a few days ago there was a post about error reports.
It occurred to me that a faster way to find the source of errors is possible.
Introducing "errorAnalyzer"...

1. Add errorAnalyzer.jar to your Additional folder

2. Add this macro to your project (Main or B4XMainPage). This will add a button to the top of the IDE.
#Macro: Title, Error Analyzer, ide://run?File=%ADDITIONAL%\errorAnalyzer.jar&Args=%PROJECT%

3. When an error occurs and you want to see the calling history of the error:
Just copy all from the log, errorAnalyzer will find the error at the end of the Log.

4. Invoke errorAnalyzer by clicking on the button at top of IDE (or type its shortcut).

5. Paste the contents of the clipboard to the designated area. Press Ready.

6. You'll see the details of the calling history

7. Press X to exit, or Copy to Clipboard. Paste the results at the END OF ANY MODULE (so line numbers aren't changed).

8. Use the included IDE Ctrl Click GoTo links to quickly go to source of error.

The .jar is too large to upload. So here is a Drop Box link - Version 1.03
https://www.dropbox.com/scl/fi/sefr...ey=e14l4a0mmcvi7h8dof1lov6sb&st=mi2cs72o&dl=0

The jar file is inside the zipped folder EAnalyzerV1_03.zip

 

[cklester]

Nice! This should be built-in to the IDE...

 

[William Lancee]

Nice! This should be built-in to the IDE...

I agree. But after putting the .jar in Additional..
the IDE will take care of the rest with this Macro, it adds a button to the top header of the IDE.

#Macro: Title, Error Analyzer, ide://run?File=%ADDITIONAL%\errorAnalyzer.jar&Args=%PROJECT%

I am still testing various situations: it works in Release or Debug mode.
I'll look at console apps in B4J and test with B4A.

In future posts I will provide source code and an explanation of how it works.

 

[William Lancee]

It works in B4A in both Release and Debug mode.
In B4J console mode it misses a stack level. I'll look at it tomorrow.

 

[William Lancee]

[Note: There is a new version of the errorAnalyzer.jar in post #1 to fix a B4J console app problem. Please use that version.]

Here is how errorAnalyzer works.

The Objects folder has a subfolder called src.
During compilation each b4x line is transpiled to Java and the B4X line is inserted as a Java comment before the Java code lines (which can be 1 or more lines).
In that comment is a line number - but in debug mode this number appears to be all over the place.
But it isn't random! The number is sequential within a Sub. This is the key to a solution.

Now we can convert the Java line number to a relative position to the start of a Sub. This works in both Debug and Release mode.
This relative number can then be added to the B4X source Sub starting line number to get the calling source line number and text.
The B4X Sub starting and ending line number can be generated from the source .bas, .b4j, .b4a files.
Then we have all the pieces we need to automate this.

It turns out that the Sub starting java line number is not obvious if the the Sub is a resumable sub.
A more consistent index is the End Sub Line number. So that is is what I use.

Steps...
1. Index the End Sub line numbers of a module's B4X source for each Sub.
2. In the Java code of the module, find the line Number reference of the "End Sub" following the error.
3. Compute the relative # lines of the error to the "End Sub" in the .java file.
4. Compute the B4X line number from the B4X source sub info.

As simple as that!

 

[AnandGupta]

As simple as that!

Really !
How teachers say to the bewildered class, after explaining integral problem !


BTW thanks for your effort

 

[William Lancee]

v1.03 Link in #1 is updated.

1. Expanded source code locations to include absolute file locations, see reference:
https://www.b4x.com/android/forum/threads/ide-state-and-code-bundle-jsons.170830/post-1045569

2. I use BBCodeView a lot, so I added a feature to show the source of the mismatched or erroneous tags - skipping internal codeview calls.

Note: The project location of the current project is automatically inserted. The Browse button can be used to analyze errors from another project.

When you paste the result, it also shows that the source of library modules are not available tor computing code lines.