fix(ios): manually evaluate all error properties

[janvennemann]

JIRA: https://jira.appcelerator.org/browse/TIMOB-27827

Starting with iOS 13.4 JavaScriptCore follows the spec and makes all Error properties non-enumerable. This breaks our existing conversion from JS error object to native since we relied on property enumeration. To address the issue our runtime will now manually check for available properties on the error object and populate the values to the native TiScriptError.

[build]

	Messages
📖	💾 Here's the generated SDK zipfile.
📖	✊ The commits in this PR match our conventions! Feel free to Rebase and Merge this PR when ready.
📖	✅ All tests are passing Nice one! All 6636 tests are passing. (There are 697 skipped tests not included in that total)

Generated by 🚫 dangerJS against 3b9039e

[sgtcoolguy]

I suspect it's not as simple as this as I assume this affects our crash reporting, cc @garymathews

[vijaysingh-axway]

@janvennemann defaultExceptionHandler is a method not property. I think it should be used as [TiExceptionHandler defaultExceptionHandler]. Same applies for other places.

[janvennemann]

Technically, a property will only create a variable and getter/setters for you and the compiler will automatically call the getter method when you access the property. By using TiExceptionHandler.defaultExceptionHandler here I just instruct the compiler to automatically call the method defaultExceptionHandler, so it shouldn't make a difference.

[vijaysingh-axway]

@janvennemann I think two methods you introduced in TiExceptionHandler are not required. You can get TiScriptError by using the new method in TiUtils. Something like below -

[TiExceptionHandler.defaultExceptionHandler reportScriptError:[TiUtils scriptErrorFromValueRef: exception inContext: context.context]];

[janvennemann]

Sure, they are not required. However, i added them purely for convenience reasons since we have different source types that we need to create TiScriptError from. I didn't like repeatedly having to use [TiUtils scriptErrorFromValueRef: exception inContext: context.context]] all over the place so i moved that into the two new methods.

IMHO [TiExceptionHandler.defaultExceptionHandler reportScriptError:exception inKrollContext:context]; looks nicer and is easier to read than having a nested method. Another benefit is that we only need to adjust the TiUtils usage in one place should we ever need to change this again.

[vijaysingh-axway]

In aca module, I can't see if anything will get affected. ACA is receiver of TiScriptError and NSException from TiExceptionHandler via delegate.

[vijaysingh-axway]

See the comments please.

[vijaysingh-axway]

Looks good.

[ssekhri]

@janvennemann An error report is shown when we explicitly throw an error from the code. However there is a difference in behavior when I compare between iOS 13.4 and older iOS version. The app closes from the code block which throws an error on iOS 13.4 whereas on older version (I tested 12.2) the error is thrown but the app continues.
To reproduce:

1. Create a default alloy app
2. In index.js changed the doClick() as follows
   function doClick(e) { alert($.label.text); try { throw new Error('example exception'); } catch (e) { aca.logHandledException(e); } }
3. Run on iOS sim
   On iOS 13.4, as soon as we click on "Hello World" the app closes. An error report is shown in logs.
   On iOS 12.2 on click of Hello World the alert message is shown and error report is also shown in logs.

[ssekhri]

Tested on iOS 13.4 device and got the crash logs.

CrashLog.zip

[ssekhri]

FR Passed.
Thrown error reports shown with all properties and no crash observed.
Verified on:
Mac OS: 10.15.4
SDK: 9.1.0.v20200408132629
Appc CLI: 8.0.0
JDK: 11.0.4
Node: 10.17.0
Studio: 6.0.0.202003181504
Xcode: 11.4
Device: iPhone X(v13.4), iOS simulator 13.4, iOS simulator 12.2