B4J Question catch an error in release mode by log

[rbirago]

When I check an app in debug mode it's easy to understand where the error is, because in the log is reported which is the module and b4j line of the error.
In release mode the check is not so easy: in my example there is a server application in which the log file is redirected on a file.
The Server app is normally stable, but sometime it has some troubles. Looking at the log I see an error warning issued by java, but I cannot understand where to look in my modules to inspect the code. see for example this chunk of log:

main._appstart (java line: 192)
java.lang.RuntimeException: java.lang.UnsupportedOperationException
    at anywheresoftware.b4a.BA.raiseEvent2(BA.java:138)
    at anywheresoftware.b4a.BA$3.run(BA.java:265)
    at anywheresoftware.b4a.keywords.SimpleMessageLoop.runMessageLoop(SimpleMessageLoop.java:47)
    at anywheresoftware.b4a.StandardBA.startMessageLoop(StandardBA.java:43)
    at anywheresoftware.b4a.keywords.Common.StartMessageLoop(Common.java:175)
    at com.ab.template.main._appstart(main.java:192)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at anywheresoftware.b4a.BA.raiseEvent2(BA.java:109)
    at anywheresoftware.b4a.BA.raiseEvent(BA.java:96)
    at com.ab.template.main.main(main.java:28)
Caused by: java.lang.UnsupportedOperationException
    at java.base/java.util.AbstractList.remove(AbstractList.java:167)
    at java.base/java.util.AbstractList$Itr.remove(AbstractList.java:387)
    at java.base/java.util.AbstractList.removeRange(AbstractList.java:598)
    at java.base/java.util.AbstractList.clear(AbstractList.java:243)
    at anywheresoftware.b4a.objects.collections.List.Clear(List.java:74)
    at com.ab.template.shgen._email_messagesent(shgen.java:370)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at anywheresoftware.b4a.BA.raiseEvent2(BA.java:109)
    ... 12 more

main.main (java line: 28)
java.lang.RuntimeException: java.lang.RuntimeException: java.lang.UnsupportedOperationException
    at anywheresoftware.b4a.BA.raiseEvent2(BA.java:138)
    at anywheresoftware.b4a.BA.raiseEvent(BA.java:96)
    at com.ab.template.main.main(main.java:28)
Caused by: java.lang.RuntimeException: java.lang.UnsupportedOperationException
    at anywheresoftware.b4a.BA.raiseEvent2(BA.java:138)
    at anywheresoftware.b4a.BA$3.run(BA.java:265)
    at anywheresoftware.b4a.keywords.SimpleMessageLoop.runMessageLoop(SimpleMessageLoop.java:47)
    at anywheresoftware.b4a.StandardBA.startMessageLoop(StandardBA.java:43)
    at anywheresoftware.b4a.keywords.Common.StartMessageLoop(Common.java:175)
    at com.ab.template.main._appstart(main.java:192)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at anywheresoftware.b4a.BA.raiseEvent2(BA.java:109)
    ... 2 more
Caused by: java.lang.UnsupportedOperationException
    at java.base/java.util.AbstractList.remove(AbstractList.java:167)
    at java.base/java.util.AbstractList$Itr.remove(AbstractList.java:387)
    at java.base/java.util.AbstractList.removeRange(AbstractList.java:598)
    at java.base/java.util.AbstractList.clear(AbstractList.java:243)
    at anywheresoftware.b4a.objects.collections.List.Clear(List.java:74)
    at com.ab.template.shgen._email_messagesent(shgen.java:370)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at anywheresoftware.b4a.BA.raiseEvent2(BA.java:109)
    ... 12 more

so: how to understand where to inspect my code to manage the problem?
Thanks
Roberto

 

[DonManfred]

so: how to understand where to inspect my code to manage the problem?

Hiding the code you are using and which raises this error) is of no help to help you.
Are you trying to remove an item from a List? Is it a readonly list?

Post a small project showing the problem.

 

[rbirago]

that's the problem: The server app normally works without problems. If suddenly appears a log warning like this where can I find almost the module crashes?. I have no idea where the problem is, so I cannot reproduce the issue. Actually I also have the doubt that the error is during a remove of an element of a list, but in the entire app there are plenty of modules in which there are instructions of RemoveAt . How to understand from the log in which module/sub this error is generated? (the server app is a web application and I don't know what a user was doing generating the problem).

 

[DonManfred]

com.ab.template.shgen._email_messagesent

i would start here with the search...

 

[rbirago]

ok, this a good start point to check: thank you.
So, as general rule: in these situations I have to inspect in all the log if somewhere it is mentioned a sub of the app. Is it right?

 

[DonManfred]

Is it right?

kind of.... the stacktrace starts at the point crashing. you have to follow the trace up to a point where you see your code mentioning..

 

[Harris]

Use Try / Catch / End Try and log the exceptions logically - anywhere you use RemoveAt... (or other suspects)
Otherwise, how can one ever tell where an occasional problem exists?