More on sun.dc.pr.PRException: endPath: bad path

[Jack Basiago]

I have found some information about this exception that I thought would be valuable. I have run across this exception using Time Series charts and XY Charts. I was able to set up my debugger to break when the exception was thrown. At that point, I was able to walk back up the stack and find the problem. In my case, the exception was being thrown while in the StandardXYItemRenderer.drawItem() routine during the g2.draw(line) call (line 310) . When I closely inspected the line that was being passed to the routine, I found that at least one of the point values was way out of range. I followed this clue back to the translateValueToJava2D calls further up the routine. I discovered that there is a potential divide by zero possiblity in these routines. Take com.jrefinery.chart.HorizontalNumberAxis for instance;

public double translateValueToJava2D(double value, Rectangle2D dataArea) {

double axisMin = range.getLowerBound();
double axisMax = range.getUpperBound();
double minX = dataArea.getX();
double maxX = dataArea.getMaxX();
if (inverted) {
return maxX - ((value - axisMin)/(axisMax - axisMin)) * (maxX - minX);
}
else {
return minX + ((value - axisMin)/(axisMax - axisMin)) * (maxX - minX);
}

}

If axisMin - axisMax is zero or close to zero, the returned value will get very large and cause the g2.draw(line) to throw the exception. I modified this code to;

public double translateValueToJava2D(double value, Rectangle2D dataArea)
{
double axisOrg = range.getLowerBound();
double axisLength = range.getLength();
double minX = dataArea.getX();
double maxX = dataArea.getMaxX();
if (inverted)
{
if ( axisLength > ( Math.abs( value - axisOrg ) / 1000.0 ) )
{
return maxX - ((value - axisOrg)/(axisLength)) * (maxX - minX);
}
else
{
return maxX;
}
}
else
{
if ( axisLength > ( Math.abs( value - axisOrg ) / 1000.0 ) )
{
return minX + ((value - axisOrg)/(axisLength)) * (maxX - minX);
}
else
{
return minX;
}
}
}

This version checks for the range length being close to zero when compared to the value being plotted. If it is, the method returns a bound of the rectangle that is passed in. This seems to work even during zooming and will never cause the exception to be thrown (in my experience thus far). I found the same problem in classes HorizontalDateAxis and VerticaNumberAxis. These are the only classes my application is using but I suspect the logic error may exist elsewhere.

Hope this is helpful. I'll be happy to provide further details if needed. I've only been using this product for about a month and I love it. I can't understand why anyone would spend $1000+ for a graphing package.

Thanks
Jack

[David Gilbert]

Hi Jack,

Thanks for your post. This looks like a reasonable approach to eliminating extreme values (which are usually the source of those exceptions). My only thought (without having tried your code yet) is that occasionally a data item might be visible on the edge of the chart when it should be invisible (because although the point is well outside the axis range it is now being mapped to the max or min value). A scatter plot is one example where this might happen...have you noticed anything like that?

Regards,

DG.

[Jack Basiago]

Like I said, I've only really needed the xy and time series charts thus far. I'll check it out if I get a chance. I had the same thought about values on the edge. I did check to see that zoom seemed to work correctly (thinking that the display would exhibit "clipping" at the border). Zoom seemed to work perfectly. Not being that familiar with the code, I was happy to resolve the problem to this point. As I use the product more, I'll keep you informed of anything else I find.

Regards,

Jack