Rationale
Having an app that extensively uses dynamic data, coupled with location-specific events, it is very hard to exactly reproduce errors that occur in the application. It is absolutely necessary for there to be a global onerror event that can be accessed in a production environment, that can grab the error that occurred and report it back along with the stack.
Problem
Crash reports did get through with no JS nor Ti references. _Non native developers_ wouldn't be able to catch up such errors in a timely fashion.
Use case
A *NSRangeException* from a Crittercism crash report, is being thrown multiple times on production environment:
Crashed Thread
0
CoreFoundation 0x333842a3 __exceptionPreprocess + 163
1
libobjc.A.dylib 0x3b0a197f objc_exception_throw + 31
2
CoreFoundation 0x332cfb75 -[__NSArrayM objectAtIndex:] + 165
3
INSPI 0x00062bf5 -[TiUITableViewSectionProxy rowAtIndex:] (TiUITableViewSectionProxy.m:113)
4
INSPI 0x000a5391 -[TiUITableView triggerActionForIndexPath:fromPath:tableView:wasAccessory:search:name:] (TiUITableView.m:906)
5
INSPI 0x000aa12d -[TiUITableView tableView:didSelectRowAtIndexPath:] (TiUITableView.m:2088)
6
UIKit 0x3524e28d -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 877
7
UIKit 0x352d0f81 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 157
8
Foundation 0x33c92277 __NSFireDelayedPerform + 451
9
CoreFoundation 0x333595df __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 15
10
CoreFoundation 0x33359291 __CFRunLoopDoTimer + 273
11
CoreFoundation 0x33357f01 __CFRunLoopRun + 1233
12
CoreFoundation 0x332caebd CFRunLoopRunSpecific + 357
13
CoreFoundation 0x332cad49 CFRunLoopRunInMode + 105
14
GraphicsServices 0x36ea12eb GSEventRunModal + 75
15
UIKit 0x351e0301 UIApplicationMain + 1121
16
INSPI 0x0004a5d3 main (main.m:36)
17
INSPI 0x0004a010 start + 40
Concept
A global onerror event that can be accessed in a production environment will allow to figure out root cause problem quicker.
With a app-wide error event, We would like to retrieve:
1. the file that the error occurred in (including path)
2. the line number of the error
3. the error that was thrown
4. the stack trace that lead to the error
Proposed Ti equivalent
Ti.App.addEventListener('error', function(e){
//e.error
//e.stack
});
It seems trivial to add such a hook to the titanium SDK, as in development, a red window appears showing the error. Whatever event that is hooking into needs to be exposed to the developer as well.
Not sure why this is assigned to me.
This would be epic, +1! Crash reporting would be great, but many times a JS error halts the functioning of a production app without resulting in a crash, so those errors never get attention unless the user reports them. An event we can listen to would handle this perfectly for my needs as well.
For anyone still curious about this, I'm using https://github.com/dbankier/TiLogCatcher to listen for JS errors.