Javascript exception control

[dark_gf]

Hi all,

I have a problem: in my job we creating ria based on extjs, and
divided code by components, all works great but its difficult to trace
errors in components, because they executed via eval() functions, does
any have any ideas how to get max information about error that happed
in code?

 

[Thomas 'PointedEars' Lahn]

I have a problem: in my job we creating ria based on extjs,

Bad idea.

and divided code by components, all works great

No, it does not. Last I checked, ExtJS was a 277K+ blob that used browser
sniffing to generate a UI that was not accessible; needlessly, I should add.

but its difficult to trace
errors in components, because they executed via eval() functions,

Don't do that, then.

does any have any ideas how to get max information about error that happed
in code?

Why not avoid the eval() problem in the first place by employing approaches
natural to competent programming?

You should get a real name if you want to have a chance to be taken
seriously here.


PointedEars

 

[dark_gf]

Extjs is not perfect but in our project we need him and don't want to
write own framework.
How dynamically load code, execute him and trace errors?

 

[David Mark]

Bad idea.


No, it does not.  Last I checked, ExtJS was a 277K+ blob that used browser
sniffing to generate a UI that was not accessible; needlessly, I should add.

Look again. It's 700K+. Or perhaps you are referring to the size
after GZIP?

 

[David Mark]

Extjs is not perfect but in our project we need him and don't want to
write own framework.

What make you think that the only two options are using Ext JS and
writing your own framework?

How dynamically load code, execute him and trace errors?

Too general. You'll never get an answer like that.

 

[Alan Gutierrez]

I have a problem: in my job we creating ria based on extjs, and
divided code by components, all works great but its difficult to trace
errors in components, because they executed via eval() functions, does
any have any ideas how to get max information about error that happed
in code?

1) Firebug.
2) Surround eval stuff with try catch and read the exception.

 

[Thomas 'PointedEars' Lahn]

[...] Last I checked, ExtJS was a 277K+ blob that used
browser sniffing to generate a UI that was not accessible;
needlessly, I should add.

Look again. It's 700K+. Or perhaps you are referring to the size
after GZIP?

I was referring to the total size of all files in in ext-core/src/core/,
which AIUI would be the minimum code required to make ExtJS work. But
the difference doesn't really matter here, does it?


PointedEars

 

[David Mark]

[...]  Last I checked, ExtJS was a 277K+ blob that used
browser sniffing to generate a UI that was not accessible;
needlessly, I should add.

Look again.  It's 700K+.  Or perhaps you are referring to the size
after GZIP?

I was referring to the total size of all files in in ext-core/src/core/,
which AIUI would be the minimum code required to make ExtJS work.  But
the difference doesn't really matter here, does it?

In what way? Certainly when it comes to bad code, it's in for a
penny...

Or perhaps you refer to the OP's use of "framework" which implies that
they are likely using the various widgets as well (pushing the
required payload over 700K).

Either way, it's a problem.

 

[David Mark]

1) Firebug.

I think it can be assumed from the OP's description that they are
already using a debugger of some sort.

2) Surround eval stuff with try catch and read the exception.

That's absolutely the wrong answer as it would prevent the debugger
from tracing and presenting the execution that led to the exception.
Not unsurprisingly, this is (sort of) what Dojo does, which makes
debugging their dynamically loaded "modules" virtually impossible.

One part of the answer to problems like these is to eliminate try-
catch clauses (particularly those that throw "friendly" replacement
errors), not to add them.

Another answer it to avoid the use of eval, which is virtually never
needed anyway.

In Dojo's case, I replaced all of their loader without using a single
eval call. The solution in their case was to use document.write
before the DOM was ready and script injection afterward. Not
unexpectedly, it made debugging infinitely easier (as well as speeding
up the loading exponentially). And no, they didn't use any of it.

ISTM they got hung up on some obscure case of using two differnt Dojo
versions in the same document. I explained that I hadn't tried that
(and neither had they with my branch), but couldn't say for sure what
the ramficiations of such a bizarre scheme would be. That was enough
for them to want to cling to their old synchronous XHR/eval version
(which remains to this day) as in their minds, it was "well-tested"
and worked in "all browsers".

 

[Alan Gutierrez]

ISTM they got hung up on some obscure case of using two differnt Dojo
versions in the same document. I explained that I hadn't tried that
(and neither had they with my branch), but couldn't say for sure what
the ramficiations of such a bizarre scheme would be. That was enough
for them to want to cling to their old synchronous XHR/eval version
(which remains to this day) as in their minds, it was "well-tested"
and worked in "all browsers".

Is there a link to this conversation on one of their development
listservs or otherwise publicly available. I'd be eager to read the
exchange and see what reasons they gave.

 

[David Mark]

Is there a link to this conversation on one of their development
listservs or otherwise publicly available. I'd be eager to read the
exchange and see what reasons they gave.

They gave no reasons rooted in reality. As I mentioned, one guy
started blathering about multiple Dojo in one page. I told him to
either refrain from worrying about that until later as none of them
had bothered to do any testing in that area anyway. Others opined
that synchronous XHR was "okay". Still others referred to my rewrite
as an "optimization" that they might use for Dojo 2.0 in some future
year. It was quite a comedy of errors that ultimately led nowhere.

And they never even commented about the debugging ease. We never got
that far. Told by various higher-ups who *had* actually bothered to
download and test my branch that it was *much* faster (for reasons
that should be obvious), they implored me to post benchmarks. I told
them that the speed difference was *palpable*, so microscopic
examination was unnecessary. AFAIK, none of the "module owners" tried
it out.

Also, one of their main refrains during these (and many related)
discussions was that patches should not need to touch more than one
"module". Told that due to interdependency the patches (or merges)
would need to touch *lots* of files, they flipped. That was a major
sticking point. Collectively, they lacked the confidence to tackle
such "major" changes.

And yes, the Dojo developer mailing list archive is supposedly
public. I heard that from them a few times. They seemed to be very
concerned that their "fans" might have been reading my warnings about
the problems in the code. Of course, IIRC, the mailing list itself
was hard to find through Google (due to broken links to older forums
and mailing lists) and anyone who was not actively involved in
developing the Dojo core would have no interest in reading it (let
alone pore through the archive!)

So go ahead and delve, but remember I warned you it was a waste of
time.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
[...] Last I checked, ExtJS was a 277K+ blob that used
browser sniffing to generate a UI that was not accessible;
needlessly, I should add.

Look again. It's 700K+. Or perhaps you are referring to the size
after GZIP?

I was referring to the total size of all files in in ext-core/src/core/,
which AIUI would be the minimum code required to make ExtJS work. But
the difference doesn't really matter here, does it?

In what way? Certainly when it comes to bad code, it's in for a
penny...

Or perhaps you refer to the OP's use of "framework" which implies that
they are likely using the various widgets as well (pushing the
required payload over 700K).

No, I was not referring to that.

Either way, it's a problem.

No doubt about that, but whether it is 277K+ or 700K+ does not really matter
to me; it is too much in either case.


PointedEars

 

[David Mark]

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
[...]  Last I checked, ExtJS was a 277K+ blob that used
browser sniffing to generate a UI that was not accessible;
needlessly, I should add.
Look again.  It's 700K+.  Or perhaps you are referring to the size
after GZIP?
I was referring to the total size of all files in in ext-core/src/core/,
which AIUI would be the minimum code required to make ExtJS work.  But
the difference doesn't really matter here, does it?

In what way?  Certainly when it comes to bad code, it's in for a
penny...

Or perhaps you refer to the OP's use of "framework" which implies that
they are likely using the various widgets as well (pushing the
required payload over 700K).

No, I was not referring to that.

Oh, sorry.

No doubt about that, but whether it is 277K+ or 700K+ does not really matter
to me; it is too much in either case.

Yes, by far. And their new "mobile" version is 228K, so they haven't
learned anything from their previous failures.