@Dean, I wrote a post in your blog which apparently discarded it completely
... anyway, somehow you already answered cause you said you use a meta
rather than document.body or document.documentElement.
My concern was about generic slowdown performances like DOMAttrModified in
Gecko if applied to th
* It effects IE 7 too (fixed in IE8)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send em
> @John Resig - Your try-finally block fails in IE6 because of this bug:
> http://webbugtrack.blogspot.com/2007/11/bug-184-catch-to-try-catch-finally-in.html
Ah, interesting - thanks for the heads-up.
--John
--~--~-~--~~~---~--~~
You received this message because
@John Resig - Your try-finally block fails in IE6 because of this bug:
http://webbugtrack.blogspot.com/2007/11/bug-184-catch-to-try-catch-finally-in.html
Also it doesn't appear to break at the correct spot either.
http://dl.getdropbox.com/u/513327/handler-fail.png
- JDD
--~--~-~--~
Here and now one has to step back and repeat the answers to these
questions :
1 .what are Browser + JavaScript for ?
2. what is Jquery for ?
3. what is server side for ?
The issue is that anyone can upload his/her infantile or brilliant
plugin to http://plugins.jquery.com/ ... Now we have a sea
Is something like this enough?
var _errors = [];
function flushErrors() {
if ( _errors.length > 0 ) {
e = _errors;
errors = [];
throw e;
}
}
function pushError( e ) {
if ( console && console.error )
console.error( e );
//if ( ... )
//...
On Mar 25, 4:38 am, John Resig wrote:
> > The point is, you cant move your mouse fast enough, or type so
> > quickly, that your event dispatch system is going to get in the
> > way. :-)
>
> It won't explicitly "get in the way" but it will certainly contribute
> to un-needed overhead. Right now we
On Mar 25, 4:36 am, John Resig wrote:
> > It doesn't break like that in MSIE as you well know.
>
> How so? I fired up my copy of IE 8 and the Script Debugger worked
> great - broke right on the throw breakpoint - virtually identical to
> Firebug (I'm really enjoying the new developer tools in IE
On Mar 25, 4:36 am, John Resig wrote:
> My reference page:http://ejohn.org/files/handler-ready.html
>
> I'll provide numbers for MSIE once I can get the example running.
>
It seems that onpropertychange is not recognised for documentElement
in quirksMode.
I don't actually use documentElement in
Thanks John to clarify me what I missed.
> The problem with your code is that you're re-throwing the event -
> which means that debuggers/command-lines will think that the error
> originated from the second throw point in the catch, and not the
> original location.
I was in hope that there is an
The problem with your code is that you're re-throwing the event -
which means that debuggers/command-lines will think that the error
originated from the second throw point in the catch, and not the
original location.
Additionally, using setTimeout is no good because the return results
from the fu
> The point is, you cant move your mouse fast enough, or type so
> quickly, that your event dispatch system is going to get in the
> way. :-)
It won't explicitly "get in the way" but it will certainly contribute
to un-needed overhead. Right now we're fighting tooth-and-nail to
squeeze every bit o
> It doesn't break like that in MSIE as you well know.
How so? I fired up my copy of IE 8 and the Script Debugger worked
great - broke right on the throw breakpoint - virtually identical to
Firebug (I'm really enjoying the new developer tools in IE 8).
> What are you measuring here? Think about
What about this:
function runHandlers(){
var h;
try {
while ( (h = handlers.shift()) ) {
h();
}
} catch (e) {
setTimeout(runHandlers);
throw e;
}
}
var handlers = [
function(){
throw "A";
},
function(){
throw "B";
}
];
This one will throw both (all)
On Mar 25, 12:29 am, Dean Edwards wrote:
> What are you measuring here? Think about that.
>
The point is, you cant move your mouse fast enough, or type so
quickly, that your event dispatch system is going to get in the
way. :-)
Think of the code I published another way, apart from setTimeout/
s
On Mar 24, 10:48 pm, John Resig wrote:
> > That's pretty neat code. But if I have an error in JavaScript then I
> > prefer the code to break where the error is. If I was using a debugger
> > to inspect the stack then I wouldn't be able to debug this because the
> > error has passed.
>
> That's no
> That's pretty neat code. But if I have an error in JavaScript then I
> prefer the code to break where the error is. If I was using a debugger
> to inspect the stack then I wouldn't be able to debug this because the
> error has passed.
That's not true, observe:
http://ejohn.org/files/handler-bre
On Mar 24, 9:13 pm, John Resig wrote:
> I don't think the order of the error is terribly important in this
> case. At the very least, though, you get the best of all worlds: All
> handlers execute, exceptions are thrown, and performance isn't
> sacrificed.
>
That's pretty neat code. But if I hav
Yes, it makes sense, further exception simply erase the previous one I guess
so when the vm retracts to the first finally, it has the last exception
thrown, not the first one and not all of them... I guess Oo
But more importantly, if we're dealing with $(document).init() for instance,
who is the ca
> Won't you get only the latest exception thrown or will you get all the
> exceptions? I never used exceptions that intensely in javascript.
Good question - in the dummy code that I posted it appears that only
the last one goes into the try/catch - but if you think about it, that
makes sense sinc
Won't you get only the latest exception thrown or will you get all the
exceptions? I never used exceptions that intensely in javascript.
2009/3/24 John Resig
>
> > I don't think it is the resposibility of the dispatcher to handle
> > exceptions.
> > I think it it is the resposibility of the disp
Sorry for the typo, DEan :(
Well, the only exceptions that the dispatcher would have to handle are
runtime ones, which as I stated, are the product of mis-programming.
I really tend to concur with the general opinion in this thread that this
kind of errors is where plugin sandboxing ends. IMO, if
> I don't think it is the resposibility of the dispatcher to handle
> exceptions.
> I think it it is the resposibility of the dispatcher to dispatch
> events. :-)
> An error in one handler should not prevent another handler from
> executing.
> Nor should a dispatcher suppress errors so that it can
On Mar 24, 8:35 pm, Julian Aubourg wrote:
> I think that's the issue Dan is talking about: throwing an exception in one
> callback shouldn't stop the whole callback loop.
> Anyway, I disagree with you John in that exception=error and I disagree with
> Dean is that it is the responsibility of the
On Tue, 24 Mar 2009 13:54:08 -0700, David Zhou wrote:
>
> On Tue, Mar 24, 2009 at 4:29 PM, Dean Edwards
> wrote:
>>
>> On Mar 24, 8:09 pm, John Resig wrote:
>>> Why would you want this?
>>>
>>
>> It will stop plugins from interfering with each other.
>>
>> If a plugin has an error in its doc
On Tue, Mar 24, 2009 at 4:29 PM, Dean Edwards wrote:
>
> On Mar 24, 8:09 pm, John Resig wrote:
>> Why would you want this?
>>
>
> It will stop plugins from interfering with each other.
>
> If a plugin has an error in its document.ready handler it will prevent
> subsequent handlers from running.
> It will stop plugins from interfering with each other.
>
> If a plugin has an error in its document.ready handler it will prevent
> subsequent handlers from running. A bad plugin can affect other jQuery
> code.
I don't buy that argument. If a plugin or other jQuery method is
malfunctioning then
Well exception doesn't always mean error.
When programming by exception you may very well use an exception as a
"current action" stopper, no matter how deep in said action (understand call
depth) the code throwing it is (exception zealots don't really like it when
you blatlantly say it but it's bas
On Mar 24, 8:09 pm, John Resig wrote:
> Why would you want this?
>
It will stop plugins from interfering with each other.
If a plugin has an error in its document.ready handler it will prevent
subsequent handlers from running. A bad plugin can affect other jQuery
code.
Read the article again.
I don't understand the point of it - so you have code that throws an
exception (obviously indicating that something is broken) and you
expect it to do what... still try to run? Exceptions are the universal
indicator that something is broken and not working. I understand his
implementation but he d
30 matches
Mail list logo
