is this a bug in d3 ??

[marc fawzi]

customSketch.append("circle")
.attr("x", x)
.attr("y", y)
.attr("radius", 0)
.attr("fillStyle", "rgb(255,127,0)")
.transition()
.ease("linear")
.duration(circlesInDuration)
.attr("radius", newSize)
.attr("fillStyle", newColor)
.each("end", function(d) {
d3.select(this).transition().ease("linear").duration(circlesOutDuration).style("opacity", 1e-6).each("end", function(d) {
d3.select(this).remove();
})
})

This works if I put .attr("radius", 0) in place of .style("opacity", 1e-6)

When the latter is used, I get this:

"Uncaught TypeError: Cannot call method 'setProperty' of null "

When I click on the error, it shows this portion of the d3 code:

  d3_transitionPrototype.styleTween = function(name, tween, priority) {
    if (arguments.length < 3) priority = "";
    return this.tween("style." + name, function(d, i) {
      var f = tween.call(this, d, i, window.getComputedStyle(this, null).getPropertyValue(name));
      return f === d3_tweenRemove ? (this.style.removeProperty(name), null) : f && function(t) {
        this.style.setProperty(name, f(t), priority);
>>> Uncaught TypeError: Cannot call method 'setProperty' of null
      };
    });
  };

[Mike Bostock]

You don't need to use each("end") to remove nodes at the end of the
transition; just use transition.remove().

https://github.com/mbostock/d3/wiki/Transitions#wiki-remove

Also, are you using custom DOM elements or something? I don't
recognize those attributes, so perhaps you are trying to set a style
on a non-HTML element, which may not support styles?

Mike

[marc fawzi]

Thanks Mike.

I will debug and get back to you. 

I didn't realize that UnknownHTMLElement could have no style object. But maybe... 

[marc fawzi]

yup! 

That was it: the custom element (which I believe is of type HTMLUnknownElement) or has no style object.

Sorry about that. 

Can the D3 error messages be a little more verbose or specific? For example, in this case would it have been possible to say "element has no style object" ?

[Nate Vack]

On Mon, Oct 8, 2012 at 1:25 PM, marc fawzi <marc....@gmail.com> wrote:

> Can the D3 error messages be a little more verbose or specific? For example,
> in this case would it have been possible to say "element has no style
> object" ?

Not commenting on whether it's practical to make the error message
more descriptive, but using Firebug to do a stack trace when it hits
the error might help you out.

-n

[marc fawzi]

Re: error messages

In this case, the browser thru the error, not D3 so asking D3 to give us a more descriptive message doesn't help. It just doesn't have the error handling to produce any such messages.

Re: stack trace

As a last resort, setting a break point and stepping into the code obviously helps but is tedious (esp for relative noobs where errors are encountered often) and I think this issue has been brought up many times with the conclusion being that D3 runs fast without error checking.... 

Chrome, which I use as my main dev browser, is not perfect when it comes to stack traces:

http://code.google.com/p/chromium/issues/detail?id=136546

[Nate Vack]

On Mon, Oct 8, 2012 at 2:21 PM, marc fawzi <marc....@gmail.com> wrote:

> As a last resort, setting a break point and stepping into the code obviously
> helps but is tedious (esp for relative noobs where errors are encountered
> often) and I think this issue has been brought up many times with the
> conclusion being that D3 runs fast without error checking....

Hm. With Firebug, at least, I think you can get a stack trace on an
actual exception, as opposed to setting breakpoints and stepping into
things. Whether that does something useful in this case, I'm not sure.

In the Sources tab in Chrome's debugger, you can hit the little
"pause" button at the bottom to tell the debugger to break on all
exceptions, or just uncaught ones.

Blindly stepping will drive you nuts, yeah.

-n

[Marc Fawzi]

The problem with Pause on Source when ur debugging code that has a lot going on at "once" is it depends when u hit Pause. You could end up deep in the internals of D3 and be taken on a real journey or you could get lucky and end up in ur own source. It basically breaks wherever it happens to be. Or is that not the full story? Maybe if I explicitly select the script I need to work with then it may wait until the execution is happening there then break? But I just cant see that to be the case.

As far as the Call Stack tab on Chrome devtools in the Source panel, I haven't poked there much. Maybe that's where I should go first...

Will check it out. Thanks and maybe someone out there will put together a YouTube video for Tips for Debugging D3 code... :)

Sent from my iPhone

[Nate Vack]

On Mon, Oct 8, 2012 at 3:15 PM, Marc Fawzi <marc....@gmail.com> wrote:
> The problem with Pause on Source when ur debugging code that has a lot going on at "once" is it depends when u hit Pause. You could end up deep in the internals of D3 and be taken on a real journey or you could get lucky and end up in ur own source. It basically breaks wherever it happens to be. Or is that not the full story? Maybe if I explicitly select the script I need to work with then it may wait until the execution is happening there then break? But I just cant see that to be the case.

Ah -- you don't want to have it pause at some random point in the
code; you want it to pause when an uncaught exception is raised.

> Will check it out. Thanks and maybe someone out there will put together a YouTube video for Tips for Debugging D3 code... :)

D3 isn't special -- general javascript debugging techniques will serve
you just fine here. See, for example:

https://developers.google.com/chrome-developer-tools/docs/scripts-exceptions

-n

[marc fawzi]

I had no idea I could Pause *after* an uncaught exception is thrown :) Seemed weird to think that you can pause something that has already crashed.