Always print Java tracebacks when errors happen in R5

[mattwigway]

When an error happens in R5, we often get a pretty useless error message. e.g. the error that led to discovering #514 was

Error in .jcall("RJavaTools", "Ljava/lang/Object;", "invokeMethod", cl, :  java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException

The first step to debugging this was to get a full Java traceback so I could see where the error was actually coming from in R5. I ended up hacking r5r using the changes in e9b7026 to get it to print a traceback. I'm not sure if this is the best way to do it, as the .jcall syntax needed to make .jgetEx work is much clunkier than the syntax we've been using, but I do think we should expose these errors whenever they happen to ease debugging.

[rafapereirabr]

Hi @mattwigway , it would be wonderful if you could find a way to decipher error messages from R5 lol

[mattwigway]

I think the basic issue is that something like "java.lang.ArrayIndexOutOfBoundsException" is a completely useless message even to someone familiar with the R5 internals, because that could be coming from anywhere. If we had the Java traceback, then at least we could see where the error was occurring.

[BardyBard]

Hi @mattwigway,

Just thinking out loud here. Could we not place a try catch block around every method in R5RCore to catch any exception? This way we could simply use the existing LOG setup.

[mattwigway]

Yes, that would work. We'd need to re-throw the exception after printing the stack trace so that we get an error on R side as well.

…

On Mon, Sep 15, 2025, 4:40 AM Alex Magnus ***@***.***> wrote: *BardyBard* left a comment (ipeaGIT/r5r#515) <#515 (comment)> Hi @mattwigway <https://github.com/mattwigway>, Just thinking out loud here. Could we not place a try catch block around every method in R5RCore to catch any exception? This way we could simply use the existing LOG setup. — Reply to this email directly, view it on GitHub <#515 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEKNLTK3LOXFXA46FR7JB33SZ3QRAVCNFSM6AAAAACGLVZVDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEOJRGA2TGOBTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mattwigway]

Another thought I had here - R5RCore has gotten kind of out of hand, it's close to 1000 lines now. A lot of it is boilerplate code to set up different kinds of processes - I wonder if a long-term refactor would be to move all of this into constructors that take R5RCore as an argument, so (for example) all of the travel time matrix code is in TravelTimeComputer.java. I think we could then implement a lot of error handling in R5Process and have it apply to all the R5Process subclasses.

[rafapereirabr]

I like the suggestion, Matt. This sounds like a good way forward to keep the code easier to maintain.