Android Question Select Case compiles ok but run no good

[Scantech]

I know the Select Case statement is large. When i run the class it leads to this error. But when i compile, it is ok. Should I be concerned with this? Will it pose a problem if i don't split it? It did compile ok.

B4A Version: 9.01.2
Java Version: 8
Parsing code. (0.45s)
Building folders structure. (0.01s)
Compiling code. (1.48s)
Compiling layouts code. (0.00s)
Organizing libraries. (0.00s)
Generating R file. (0.00s)
Compiling debugger engine code. Error
B4A line: 7258
Return \
javac 1.8.0_101
shell\src\cargauge\j1979definitionlibrary\j1979definitionlibrary_subs_0.java:17207: error: code too large for try statement
catch (Exception e4305) {
^
1 error

 

[Cableguy]

I remember reading somewhere that nested IFs and long/complex Select Case could have some limitations… I'll try to find where I read it

 

[Scantech]

I think it is safe. Because i ran the project in debug it failed. Ran it in Release mode it did run without any errors. Safe to say its good in compilation mode.

 

[emexes]

It looks like an error from the Java compiler, eg: http://support.veryant.com/support/phpkb/question.php?ID=97 which states:

This error is due to a limit on the number of source lines the Java compiler allows in a single block.

(I later found a better discussion of the issue at: https://www.javaworld.com/article/2073208/reproducing--code-too-large--problem-in-java.html)

and so I guess:

in release mode, your nnn lines of BASIC code is translated/compiled by B4A to ooo lines of Java that is less than the abovementioned limit,
and thus the Java compiler is ok with,

but:

in debug mode, B4A is adding extra debug-related lines of Java code that results in ppp lines of Java that is over the abovementioned limit, and thus the Java compiler emits the "code too large" error to B4A which then handballs back to you.

Should I be concerned with this?

Me personally, if I got that message, I'd be keen to get rid of it, and would try to restructure my code to resolve the situation.

Like, if it is a Select Case inside the Catch part of a Try statement, then I'd try moving that error-handling code into a separate Sub.


p.s. Minor observation, not sure if it matters, but: the error says a Try statement (Catch block?) is too large, not a Select Case statement

error: code too large for try statement catch

 

[emexes]

I know the Select Case statement is large.

Any chance of posting a sample of the code that causes the "code too large" error? I'm intrigued by what block of code would generate more than 64k of compiled byte code... that sounds like a lot of typing.

No worries if you'd rather not, eg prefer keep commercial code private.

 

[Erel]

I remember reading somewhere that nested IFs and long/complex Select Case could have some limitations

There are no limitations. In the early days of B4A Select Case blocks could not be nested, this is no longer the case.

In most cases where you see such errors it means that you are doing something wrong. Usually it happens when you combine the program data inside the code. This is a common mistake. One solution is to split the sub. A better solution is to move the data to a file.

 

[Scantech]

This is a common mistake. One solution is to split the sub. A better solution is to move the data to a file.

I wish i thought of it 8 years ago. I like the idea moving data to file but its way too many codes. I rather split the sub for now.

One question. When i compiled it and used the library with another project running in debug mode did not cause any errors?

 

[emexes]

When i compiled it and used the library with another project running in debug mode did not cause any errors?

I am guessing it is because the library code was compiled in release mode, without the extra Java code lines added for debugging.

This link https://www.javaworld.com/article/2073208/reproducing--code-too-large--problem-in-java.html says that the limit is 65535 bytes of compiled byte code, which makes me think that it is something to do with byte code jump destinations being 16 bits.

65k of compiled code is a pretty big Sub, eg, if an average B4A line compiled to 15 bytes, then that's 4000 lines = 60 pages of code, which seems like a pretty generous limit for one Sub or block or whatever the limit applies to.