Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-10505] Android: Expose runtime errors to module developers

GitHub Issuen/a
TypeNew Feature
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2013-01-29T17:41:25.000+0000
Affected Version/sRelease 3.0.0
Fix Version/sRelease 3.0.0, Release 3.0.1, Sprint 2012-18 Core, 2012 Sprint 18
ComponentsAndroid
Labelscore
ReporterAllen Yeung
AssigneeAllen Yeung
Created2012-08-20T18:12:08.000+0000
Updated2013-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

FileDateSize
app.js2012-09-10T16:12:29.000+0000980
com.exceptionhandler-android-0.1.zip2012-09-10T16:12:29.000+000049798
ExceptionhandlerModule.java2012-09-10T16:31:29.000+00003012

Comments

  1. Allen Yeung 2012-09-06

    PR Ready: https://github.com/appcelerator/titanium_mobile/pull/2879 For testing, put some bad code in app.js like:
       win.open();
       
    Verify that the error dialog pops up as usual. This should be tested in BOTH V8 and Rhino.
  2. Allen Yeung 2012-09-06

    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.
  3. Allen Yeung 2012-09-10

    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:
       D/ExceptionhandlerModule(20757): (KrollRuntimeThread) [5998,257272] ---------------- Additional listener fired1
       
    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:
       I/ExceptionhandlerModule(20757): (KrollRuntimeThread) [5964,361847] ---------------- New primary exception handler fired
       
    Please test this on both V8 and Rhino. Afterwards, feel free to try any other combination.
  4. Allen Yeung 2012-09-10

    FYI, I've also attached the ExceptionhandlerModule.java file in case anyone wants to see how I called the new APIs introduced.
  5. Natalie Huynh 2012-11-13

    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
  6. Allen Yeung 2012-11-14

    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.
  7. Ingo Muschenetz 2012-12-21

    Needs retest, please.
  8. Paras Mishra 2013-01-28

    "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
  9. Allen Yeung 2013-01-29

    Just ran this against 3_0_X and got the following:
       D/ExceptionhandlerModule( 6932): (KrollRuntimeThread) [25868,56830] ---------------- Added exception handler1
       D/ExceptionhandlerModule( 6932): (KrollRuntimeThread) [1074,57904] ---------------- Added exception handler2
       D/ExceptionhandlerModule( 6932): (KrollRuntimeThread) [6164,64068] ---------------- Removed exception handler2
       D/ExceptionhandlerModule( 6932): (KrollRuntimeThread) [2691,66759] ---------------- Additional listener fired1
       D/ExceptionhandlerModule( 6932): (KrollRuntimeThread) [29507,96269] ---------------- Removed exception handler1
       I/ExceptionhandlerModule( 6932): (KrollRuntimeThread) [12004,108273] ---------------- New primary exception handler fired
       
    "Additional listener fired1" does occur for me.
  10. Lokesh Choudhary 2013-02-11

    Verified the issue by running the attached app.js & module & saw the expected output.
        D/ExceptionhandlerModule( 3041): (KrollRuntimeThread) [16121,46570] ---------------- Added exception handler1
        D/ExceptionhandlerModule( 3041): (KrollRuntimeThread) [11801,58371] ---------------- Added exception handler2
        D/ExceptionhandlerModule( 3041): (KrollRuntimeThread) [8914,74118] ---------------- Additional listener fired1
        D/ExceptionhandlerModule( 3041): (KrollRuntimeThread) [14554,119141] ---------------- Removed exception handler1
        I/ExceptionhandlerModule( 3041): (KrollRuntimeThread) [10311,129452] ---------------- New primary exception handler fired
        
    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

JSON Source