[TIMOB-10505] Android: Expose runtime errors to module developers
GitHub Issue | n/a |
Type | New Feature |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2013-01-29T17:41:25.000+0000 |
Affected Version/s | Release 3.0.0 |
Fix Version/s | Release 3.0.0, Release 3.0.1, Sprint 2012-18 Core, 2012 Sprint 18 |
Components | Android |
Labels | core |
Reporter | Allen Yeung |
Assignee | Allen Yeung |
Created | 2012-08-20T18:12:08.000+0000 |
Updated | 2013-02-16T00:38:47.000+0000 |
Description
Currently module developers have no way to access runtime errors that occur. The errors go directly through the TiJSErrorDialog class and it can not be intercepted to do anything else.
We need to provide a mechanism for module developers to grab the error information and use it for their needs. This can be achieved either through some 'error' event that they can listen to or we could add some hook inside the TiJSErrorDialog class that is called right before we launch the dialog.
1) Titanium is currently trapping all unhandled exceptions. Instead, we need to chain the exception handlers. Module developers have to have the default handler called at some point, so they can get to the exception information.
2) If there is an exception, it might be hard to know which JavaScript method was responsible. One potential solution might be for the to automatically instrument the native, generated code. This can be done by inserting the name of the Javascript method call using Crittercism's breadcrumbs.
Attachments
PR Ready: https://github.com/appcelerator/titanium_mobile/pull/2879 For testing, put some bad code in app.js like:
Verify that the error dialog pops up as usual. This should be tested in BOTH V8 and Rhino.
For module developers, there is a KrollExceptionHandler interface that they can implement to deal with exceptions. Then the handler can be hooked up to the runtime by simple calling the static method: KrollRuntime.setExecptionHandler(KrollExceptionHandler handler); Modules can also subclass the TiExceptionHandler class to perform some logic before doing the default behavior.
Updated Test Case: 1. Install the attached module into your project 2. Use the app.js provided and run the app. 3. Run 'adb logcat -s ExceptionhandlerModule' on the command line 4. Click 'Add Exception Handler' twice 5. Click 'Remove Exception Handler' once 6. Click 'Trigger Error' once When you click 'Trigger Error', you should see something like:
After that, hit Continue on the error dialog and: 7. Click 'Remove Exception Handler' once 8. Click 'Overwrite Primary handler' 9. Click 'Trigger Error' You should see:
Please test this on both V8 and Rhino. Afterwards, feel free to try any other combination.
FYI, I've also attached the ExceptionhandlerModule.java file in case anyone wants to see how I called the new APIs introduced.
Tested with 3.0.0.v20121112163159 on Android Get D/ExceptionhandlerModule( 452): (KrollRuntimeThread) [1322,51567] ---------------- Additional listener fired1 Runtime error: view.methodDoesNotExist(); Do not see --------New primary exception handler fired
I just tested it and did not see the primary exception handler fired either (it shouldn't since we never overwrote it). I've updated the test case to reflect this.
Needs retest, please.
"Additional listener fired1" didn't occur on logcat while "New primary exception handler fired" occurred on logcat. Tested on : android version: 2.3.6 SDK version: 3.0.0.GA ,3.0.2.v20130126230207 CLI version : 3.0.23 OS : MAC OSX 10.7.5 XCode : 4.5.1
Just ran this against 3_0_X and got the following:
"Additional listener fired1" does occur for me.
Verified the issue by running the attached app.js & module & saw the expected output.
Thus closing the issue. Environment: Ti Studio : 3.0.2.201302041757 Ti BB SDK : 3.0.2.v20130207164659 Mac OSX : 10.8.2 CLI Version : 3.0.24-cr