Infinite Uncaught Exception Loop (Cannot tween a null)

[Ryan Ravioli]

I'm tracking down a bug somewhere in my animation creation where an element isn't setup yet. However, what is happening in my application when it encounters it is an infinite loop of Uncaught exceptions. The full message is...

Quote

Uncaught Cannot tween a null target.     TweenMax.js

 

 

I went to try and simple reproduce this in the console on this very website and my first attempt, produced the exception but not the loop. So I was confused.

var tl = new TimelineMax()
tl.to(window.foo, .1, {opacity: 1})

 

However, I realized it was actually a fromTo and not a to. So I change the example above to

 

var tl = new TimelineMax()
tl.fromTo(window.foo, .1, {opacity: 1}, {opacity: 0})

 

And bam, easily reproducible. The above exception repeats ad infinitum. I also tried it with two other from method and same results happen.
 

var tl = new TimelineMax()
tl.from(window.foo, .1, {opacity: 1});

//-OR-

var tl  = new TimelineMax()
tl.staggerFromTo([window.foo], .1, {opacity: 1}, {opacity: 1});

 

Obviously it would be swell if I handle not doing tl.from in my code if the element doesn't exist. However, this doesn't seem to protect from what if the element is removed from the DOM after being setup. This seems to be related to the requestAnimation tick loop and maybe it is always checking to see if it has made it to where its going? I'm pretty novice at GSAP and don't fully understand the internals.

 

My question is, is there a best practice (error events, configuration options, etc...) I have been unable to find that will safe guard my application from these errors or is it completely up to me?

 

My comment is for the design aspects, is this seem desirable based on how GSAP works?

 

Just kind of throwing this out there to see if I get any kinds of feedback. Thanks everyone

 

-Ryan

See the Pen zjyPrO by anon (@anon) on CodePen

[OSUblake]

I don't know why it keeps throwing an error, but it's supposed to throw an error if the target doesn't exists. If it failed silently, then it would be hard to debug.

 

Error handling is just part of development, and no, you shouldn't wrap all your code up in try... catch statements. Elements don't magically add and remove themselves from your app. Whenever something changes, you should update your code to reflect those changes. There is no easy answer on how to do that as it depends on what you're doing.

 

A simple way to prevent a null target error is to test for a truthy value.

https://developer.mozilla.org/en-US/docs/Glossary/Truthy

 

Any object will be true.

 

if (foo) {
  tl.fromTo(foo, 1, { x: 100 }, { x: 0 });
}

 

[Ryan Ravioli]

Yeah, I dig making safe calls when you are worried about elements not existing, and I am doing that in most places but you know... sometimes you miss something.

 

The exception is thrown in what I think is part of the "tick" loop. This makes it uncatchable in this case because the synchronous call just queues it up and then the async tick loop comes around and its null, and that is where the error comes from.

 

Thanks for replying though, guess the answer is just to be as safe as possible and there is no safe way to catch it at a higher level

 

[GreenSock]

2 hours ago, Ryan Ravioli said:

... sometimes you miss something.

 

Yeah, I totally get it. I don't blame you for asking about this. And yeah, I actually do know how to make the error not get thrown on every tick in your example, but I'm just not sure it's worth making that change because it's a little more code (kb) and one extra condition. Probably imperceptible, frankly, but I'm a stickler for only adding stuff if there's a clear win that's worth the cost, especially because the change would be in TweenLite which is the base for everything. Since errors generally halt JS execution anyway, it isn't like this is gonna actually solve anything except making the console less full. And again, only in a scenario that should never be allowed to happen anyway. See what I mean?

 

Welcome to the forums, by the way!