javascript - ExtJs exceptions immediately break all ExtJs components on a page -

if you've ever worked extjs, you've run nefarious "cannot read property 'dom' of null" exception. me, happens inside doinsert (the last of 14 stacks in outer trace) (extjs's code):

doinsert: function(el, o, returnelement, pos, sibling, append) {     //<my own comment>: hint: el === null (curiously not undefined?)     el = el.dom || ext.getdom(el);      var newnode;     ... } 

this happens when attempt attach extjs component (tree, grid, button, whatever) dom element not yet in dom. element in memory, constructed part of ajax request, ready inserted on success.

the problem when extjs throws, it fundamentally breaks every extjs component in page. grids, trees, menus, buttons mangled. event bindings click , hover either nothing or generate exceptions.

i mitigate against first doing document.getelementbyid check, , if result undefined, defer 100 ms , try again. ugly, works. it's expensive do. pages more complex, that's more , more document.getelementbyid defer loops; , gets harder , harder track down method inside module hasn't tested getelementbyid.

it's mess.

question: there way force extjs throw gracefully? override exception handling mechanism? flip "dontbreaktheentirepage" configuration variable?

update:

after trying go direct sencha , after few rebuffs, demonstrated problem more (i hope):

edit: sencha moderating replies original thread. if have interest in class of fault, please add discussion.

1. open docs (http://docs.sencha.com/extjs/4.1.0/)
2. open few tabs (i have ext, ext.tree.panel, ext.menu.menu, ext.abstractcomponent, , ext.draw.color)
3. open chrome dev tools , errors.
4. click , forth between tabs few times sanity check. tabs render expected, without error.
5. now, let's break page.
6. back dev tools.
7. switch console.

8. define adhoc method:

   var trycatch = function (func) {      try {         func.apply(this, array.prototype.slice.call(arguments, 1));     } catch (ex) {         var e = {             type: 'js',             message: ex.message,             detail: 'js error type: ' + ex.type + '<br/>\n' + 'stack: ' + ex.stack         };         console.error(e);     } }; 

9. define method throw exception:

   var myexceptionfunction = function () {     //demo taken straight extjs docs on ext.menu.menu     ext.create('ext.menu.menu', {         width: 100,         margin: '0 0 10 0',         floating: false,         renderto: 'thisiddoesnotexist', //and break rendered page         items: [{             text: 'regular item 1'         }, {             text: 'regular item 2'         }, {             text: 'regular item 3'         }]     }); }; 

10. execute myexceptionfunction method in trycatch wrapper:

    trycatch(myexceptionfunction); 

11. observe reported error: "cannot read property 'dom' of null"

12. now start clicking , forth between opened tabs.

13. suddenly, page exhibiting odd behavior.

14. you begin see new exceptions in console: "uncaught typeerror: cannot read property 'dom' of undefined" tabs render, in unexpected places. selected tab not updated.

now, extjs's documentation site handles fault quite well. of page still works in ways can cope with; in scenario, page crippled.

we're talking content has rendered--is in dom. cannot imagine reason exceptions thrown past point break has executed.

christopher, i'm sorry, evan's responses questions in linked thread appropriate , make lot of sense. understands you're asking , not understanding him. further research inner mechanisms of how extjs built make come realization things 'already rendered' describe them tightly linked else has layout engine. done micro-optimizations improve render speed. because it's tightly linked together, when try render thing doesn't exist, going bring whole engine down.

the misunderstanding here assumption things 'already rendered' have nothing things 'to rendered.' in extjs these things tightly coupled, , breaking 1 break other. since tight coupling necessary make library render faster (believe me, can't make render slower , still usable on ie8), 'issue' having necessary evil.

evan's example of surrounding code simple try-catch block best route if not able or not want take dev time implement solution within logic of own code.