View Full Version : Ext.Error - community input

7 Jun 2009, 8:42 AM
As mentioned in the blog (http://extjs.com/blog/2009/06/03/ext-js-30-rc2-release-stable-robust-and-enhanced/), a base error class has been added, with the intention of extending this to provide more robust error handling throughout the framework in the debug build.

This thread is intended for anyone to post constructive suggestions.

The first post will be maintained as a summary:


To report errant configuration attempts made during the development stage.
Developers will be notified when they misconfigure components.

To Do:

check if BLANK_IMAGE_URL has been modified
Interceptor to ComponentMgr.register which pops up an alert on registration of a Component id that is already registered
Attempting to renderTo or applyTo a Component which exists in the ComponentMgr
A Misconfigured JsonReader/XmlReader
Forgetting to specify a center region for a container with a layout of border
Ensure DataView is configured with tpl, store, itemSelector
items specified without layout (over-nesting)
Deprecated configs / methods are used:

id instead of StoreId
SimpleStore instead of ArrayStore


api misconfiguration

error checks wrapped with @debug to removed at build time:

/** @debug */
if(!c && Ext.layout.BorderLayout.WARN !== false){
throw 'No center region defined in BorderLayout ' + ct.id;
/** @/debug */

Or wrap into one Namespace:


7 Jun 2009, 8:46 AM
maybe post a link to the blog post for the community members that have not seen it? Eventually, this post will be burried by future posts.


12 Jun 2009, 10:02 AM
Very cool! Another debug dialect I've seen is

;;;more code

As many minifiers will treat that as debug code.

Anyway, you saw the issue I just had, where records silently failed because they shared id's. I didn't even know id's mattered for records!

Another good one that I'd appreciate would be checking on defaultType's. Often when messing with form layouts I'll leave vestigial code in the outer layout (such as a defaultType) and that will then replace what should be a form with a text field.

I know that last one would be pretty hard to implement and just DWIM (Detect,) but it would still be really nice.


16 Jun 2009, 1:09 AM
A common error could involve a mismatch in the dataIndex value of a column model and the corresponding JSON value of a grid store, causing it to render incorrectly.


Note: The error mentioned in the above link has nothing to do with the CellActions plugin from Saki.

16 Jun 2009, 3:53 AM
Some additional checks:

1. Check if 'this' isn't 'window' in the Ext.Component constructor (this happens when you call a constructor but forget the 'new' keyword)
2. Check if the container (or el) actually exists in Ext.Component.render().

16 Jun 2009, 9:38 AM
Ok, this is really weird. I've never seen this happen with ext before. I get the following exception whenever I try to save a form that doesn't have a url set:

uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: http://localhost:8080/static/js/lib/ext3/adapter/ext/ext-base.js :: asyncRequest :: line 1306" data: no]

Obviously one should set the url on a form, but it still might have been nice to have some direction about what the issue was :)

16 Jun 2009, 9:44 AM
it's probably because there is no checking to see if url string is != 'undefined' and length > 0.

18 Jun 2009, 10:11 AM
Too strict if we throw an error if IE is detected at all? >:)
(I'm having a bad IE day.)

18 Jun 2009, 11:32 AM
This could be interesting if there's a variable, like Ext.debug = true, that we can set.

Using wildcard domains or a 2nd virtual host, you could set up something like debug.yourdomain.com, and in PHP (other languages use similar technique):

if (substr($_SERVER['HTTP_HOST'], 0, 5) === 'debug') {
echo "Ext.debug=true;\n";
else {
echo "Ext.debug=false;\n";

(in the right place, of course)

29 Jun 2009, 5:50 AM
I think the Exceptions should always be thrown (whether you're in "debug" mode or not). I think how you choose to handle the Exceptions is up to you. If you'd like to have a "debug" flag that you can set to false and ignore Exceptions, that's your choice.

With that in mind, I think Ext should provide a base Exception Handler so all developers have a common foundation.

2 Jul 2009, 10:58 AM
I've noticed in RC3 that you are not removing exceptions during the build process. THANK YOU SO MUCH! :)

Please update the documentation to reflect this.

2 Jul 2009, 1:27 PM
I've noticed in RC3 that you are not removing exceptions during the build process. THANK YOU SO MUCH! :)

Please update the documentation to reflect this.

It hasn't been implemented yet, so I don't know that your conclusion will be long lived (it's correct for the time being anyway).

8 Jul 2009, 11:33 PM
Today I've seen a problem when ArrayStore is configured like this:

new Ext.data.ArrayStore({
fields: [{name:'aaa', type:'text'}]
You see the problem? There is no type 'text', only 'string'. Expected behavior for me is to throw exception during Store construction, something like "Unrecognized type: text".
Now it doesn't complain, instead it creates the field object with undefined convert function. When data is loaded, it tries to call this function, and blows up with error "f.convert is not a function", which is not very helpful.

16 Jul 2009, 12:39 PM
I had a working code in Ext 2.2, using TabPanel with same value of renderTo and id properties (see details http://extjs.com/forum/showthread.php?t=74654). Once I upgraded to 3.0 the tabPanel and rest of ExtJS components on the page weren't rendered and without showing any errors. It would probably save other people hours of debugging that I spent on this, if you could please add some kind of a error.


6 Feb 2011, 10:57 PM
With version 4 around the corner and all the awesome new features, I'm hoping to hear some new on this issue? Will we get an exception handler?