Silver's try? results in corrupted .jar: catch (Object var10) instead of Throwable

IDE: Fire
Version: 8.3.93.1987
Target jdk1.8.0_74 (Android Studio 2.1.1)
Description:
The following code compiles for both Apple’s Swift and Elements Silver toolchain.

  public subscript(z: UInt, x: UInt, y: UInt) -> QuadTreeNode? {
    		
    	guard let tileID = try? TileID(x: x, y: y, level: z) else { return nil }
    	return self.node(forTileID: tileID)
  }

However when .jar used from Android Studio Project the following runtime error is thrown:
java.lang.VerifyError: (class: geobingancore/android/QuadTree, method: getItem signature: (JJJ)Lgeobingancore/android/QuadTreeNode;) catch_type not a subclass of Throwable

This occurs in subscript(z: UInt, x: UInt, y: Uint) when you use try?, in disassembled java it look the following way. catch argument has Object type instead of Throwable.

public QuadTreeNode getItem(long z, long x, long y) {
        Object tileID = null;
        TileID tmp$1 = null;

        try {
            tmp$1 = new TileID(x, y, z);
        } catch (Object var10) {
            ;
        }

        return tmp$1 == null?null:self.node(tmp$1);
    }

This is kindoff really fundamental compiler toolchain issue when you use optional try?.
However the error resolved when you rewrite subscript(z: UInt, x: UInt, y: Uint) in more classical way:

public subscript(z: UInt, x: UInt, y: UInt) -> QuadTreeNode? {
		
	do {
		let tileID = try TileID(x: x, y: y, level: z)
		return self.node(forTileID: tileID)
	} catch {
		return nil
	}
		
}

The resulting Java disassembly will then look valid:

public QuadTreeNode getItem(long z, long x, long y) {
        QuadTreeNode Result = null;

        try {
            TileID tileID = new TileID(x, y, z);
            Result = self.node(tileID);
        } catch (Throwable var10) {
            Result = null;
        }

        return Result;
    }

I’ve seen this as well, but never go around to making a test case
As an aside, do you guys do any java verifying, or android dexing in your unit/integration tests for Silver?
I think the majority of issues I seem to log with Silver don’t show up until the verify or dex stages, and they are a massive PITA to debug

I don’t really know anything about java verification (would be glad if you can share about it), but I do try to write extensive unit test in Android Studio with junit test for underlying Silver’s .jar android class library.

What I am doing is converting my Cocoa Touch Framework to cross-compiled codebase that can compile with both Elements Silver and Apple’s Swift toolchain, so I can consume it in native Xcode and Android Studio projects.

I just started with it this week and while I can eliminate the swift syntax differences and have clean code with few #if COOPER pre proc directives, the problems in compiled .jar are a bit frightening to me, since they can only be spotted on runtime, so I guess you are right, it can be a PITA, but maybe writing the extensive unit tests is the most optimal way to get along with it, given the possibility of Silver being quite fragile on this beta stage. (Is silver in beta now?)

Sorry Taras, by “You guys” I should have been more specific - the RemObjects team

Both the Java verify and the Dex process test the integrity of the generated byte code, and they spew at things like mismatched types, or throwing the wrong thing etc. Enums are still pretty fragile in Silver for instance, and cause a lot of these type of issues.
Almost always a compiler bug in Silver, which is why I asked if they test at this level.
Running Swift on Android has to be one of the biggest use cases of the Silver compiler, so IMHO running the Silver compiler test cases on Android should be a priority.

Thank you for your feedback. I guess the reliability is the big issue for enterprise-grade projects, but as long as these issues can be resolved, I will accept that.

I am doing the extensive research on what is the optimal way in our development team to develop a shared codebase for Android and iOS and after trying with RoboVM, Xamarin, React.Native, Silver seems to be quite promising in that way that you can compile the codebase with both compiler toolchain and then consume it within the scope of native projects, so there is no learning curve associated with development teams making substantial switches to .NET or .js and you can blend it nicely into existing projects.

Thanks, logged as bugs://75264

All our java testcases run with a verifier yes. The problem with java verifying is that while the verifier might succeed (not in this case), dex might fail later, when running on Android, depending on the Android version. We do our best to stop this from happening, but as far as I can find there’s no “verify this in the way android is perfectly happy with it”.

In any case I’m looking at solving this issue of course.

bugs://75264 got closed with status fixed.

This bugs://75264 fix is only available in private beta build?

It will be in the beta build of later today yes. If needed we can send a build with this fix in it to you though

That will be really great, thank you. Will the link appear in my account page?

You can run Dex straight from dx.jar as a command line tool with no dependencies, so in theory you could grab dx.jar from a bunch of sdk versions and run it as part of the tests

The nasty thing at the moment is that Dex gives no files or line numbers when it fails dexing a Silver jar. When I have to diagnose a Dex issue at the moment I grab the dx.jar and run it in the eclipse debugger with break on exceptions turned on, so I can look at the variables in the stack to work out which method its choking on. Obviously sub-optimal

Indeed but that’s only a small subclass of errors that Idex fails on. There’s a whole class of errors ART/DEX runtime side fails on that aren’t caught, things that java is perfectly fine with. That said not a bad idea, I’ll look into implementing this, but obviously this only works for testcases I already have, most if not all of which work because I explicitly tested them.

Logged as bugs://i63256.

bugs://i63256 was closed as fixed.