Titanium JIRA Archive
Alloy (ALOY)

[ALOY-54] Improve runtime error messages

GitHub Issuen/a
Resolution Date2012-07-19T11:52:03.000+0000
Affected Version/s2012 Sprint 14
Fix Version/s2012 Sprint 14
ReporterTony Lukasavage
AssigneeTony Lukasavage


Right now when a user references an unknown ID in a selector they get the very-tough-to-debug message seen in the attached screenshot:
'null' is not an object (evaluating 'element.getAttribute') (unknown file)
We need to find a way for this to be much more verbose and actually indicate where the issue is occurring. Either that, or we handle it like jQuery, where incorrect selectors fail silently: [http://stackoverflow.com/questions/3709604/why-doesnt-jquery-bomb-if-your-selector-object-is-invalid](http://stackoverflow.com/questions/3709604/why-doesnt-jquery-bomb-if-your-selector-object-is-invalid)


Screen Shot 2012-05-14 at 10.31.51 AM.png2012-05-14T07:55:50.000+000041147


  1. Tony Lukasavage 2012-05-14

    I would prefer the jQuery approach, but this will be much more difficult as the returned objects from the selectors in our case are Titanium API objects, not wrapped selector objects. We have no means currently of preventing this type of error since we have no wrapped object that supports chaining and prevent these null calls.
  2. Tony Lukasavage 2012-05-14

    I'm also not aware of any means to create a JS call stack to view where the offending failed selector exists. All of the standard JS methods mentioned for building call stacks either don't work on any/all platforms or they are deprecated. (i.e., arguments.callee.caller, (new Error).lineNumber) We don't appear to have a good way to handle this right now. The best I can do is report the text of the selector, but that can potentially exist in any file or many different places within on project.
  3. Tony Lukasavage 2012-06-27

    These runtime issues are no longer a concern without the runtime DOM

JSON Source