Serial plotter throwing NoSuchElementException for "unplottable" data

[chrstphrchvz]

When running Serial plotter in version 1.6.8, and the buffer is never populated by "plottable" data (parts of lines that can be parsed by Double.valueOf()), each line with "unplottable" data causes a long stack trace to printed to the console:

Exception in thread "AWT-EventQueue-0" java.util.NoSuchElementException
    at processing.app.helpers.CircularBuffer.min(CircularBuffer.java:42)
    at processing.app.SerialPlotter$GraphPanel.computeBounds(SerialPlotter.java:90)
    at processing.app.SerialPlotter$GraphPanel.paintComponent(SerialPlotter.java:124)
    at javax.swing.JComponent.paint(JComponent.java:1056)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paintToOffscreen(JComponent.java:5217)
    at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1579)
    at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1502)
    at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
    at javax.swing.JComponent.paint(JComponent.java:1042)
    at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
    at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79)
    at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
    at java.awt.Container.paint(Container.java:1975)
    at java.awt.Window.paint(Window.java:3912)
    at javax.swing.RepaintManager$4.run(RepaintManager.java:842)
    at javax.swing.RepaintManager$4.run(RepaintManager.java:814)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:814)
    at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:789)
    at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:738)
    at javax.swing.RepaintManager.access$1200(RepaintManager.java:64)
    at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1732)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Should the plotter "fail softly" and explain to the user that what is being received from the Arduino can't be plotted (if that is the cause), rather than print a stack trace to the console for each new line of "unplottable" data?

Here's an example sketch that prints 0-99 repeatedly (so the plot resembles a sawtooth wave), but uncommenting the statement that prints "x= " at the beginning of each line will cause it to fail to plot--each new line will result in another stack trace on the console:

void setup() {
    Serial.begin(9600);
}

//should print 0-99 repeatedly
//plot should resemble a sawtooth wave
void loop() {
    static int i = 0;
    //Serial.print("x= ");
    Serial.println(i);
    i = (i + 1) % 100;
    delay(500);
}

This issue may be present in 1.6.6 and 1.6.7 as well, though I haven't checked; the relevant code responsible for throwing the exception is slightly different due to changes in computing max and min tick marks (e.g. for multiple signals and negative signals).

(Side question: it probably doesn't matter here, but shouldn't Double.parseDouble() be used instead of Double.valueOf()? cf. http://stackoverflow.com/questions/7255078/double-valueofs-vs-double-parsedouble)

[EDIT: example sketch did not accurately reproduce issue.]