I think I have uncovered an obscure NodeBox bug that caused me to question my sanity until I was finally able to replicate it.

It appears that when you do a lookup using a list of keys, and if the range of values includes at least one floating point number and at least one null value, and you then attempt to convert the values to strings (or do anything that requires strings), you will get one of the two following errors:

java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at nodebox.function.JavaLibrary$StaticMethodFunction.invoke(Unknown Source)
at nodebox.node.NodeContext.invokeFunction(Unknown Source)
at nodebox.node.NodeContext.invokeNode(Unknown Source)
at nodebox.node.NodeContext.invokeNode(Unknown Source)
at nodebox.node.NodeContext.renderNode(Unknown Source)
at nodebox.node.NodeContext.renderChild(Unknown Source)
at nodebox.node.NodeContext.renderNode(Unknown Source)
at nodebox.node.NodeContext.renderNode(Unknown Source)
at nodebox.client.NodeBoxDocument$3.doInBackground(Unknown Source)
at nodebox.client.NodeBoxDocument$3.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at javax.swing.SwingWorker.run(SwingWorker.java:334)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

java.lang.IllegalArgumentException: java.lang.ClassCastException@2fbb3621
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at nodebox.function.JavaLibrary$StaticMethodFunction.invoke(Unknown Source)
at nodebox.node.NodeContext.invokeFunction(Unknown Source)
at nodebox.node.NodeContext.invokeNode(Unknown Source)
at nodebox.node.NodeContext.invokeNode(Unknown Source)
at nodebox.node.NodeContext.renderNode(Unknown Source)
at nodebox.node.NodeContext.renderChild(Unknown Source)
at nodebox.node.NodeContext.renderNode(Unknown Source)
at nodebox.node.NodeContext.renderNode(Unknown Source)
at nodebox.client.NodeBoxDocument$3.doInBackground(Unknown Source)
at nodebox.client.NodeBoxDocument$3.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at javax.swing.SwingWorker.run(SwingWorker.java:334)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

When you first run the network, you will probably get the Type Mismatch error. But after making a few changes (e.g. changing which node gets rendered or changing the slice parameters) you will start to see the second error instead.

The weird thing is that if you do lookups on these exact same values using a single key, no error occurs. The problem only arises when you try processing a list of two or more keys, and then only when the values returned include both a floating point number and a null value. A set of strings with a null or a set with numbers and strings or a set of just nulls does not produce the error.

I am attaching a simple network and csv file to replicate the bug. The csv file consists of a single row with four columns, A, B, C, and D. A and B contain numbers, C is empty, and D is a string. I use a slice node to select one or more keys, feed that into a lookup, and that into a string node. If I select the keys one at a time I get the following strings

KEY : RESULT
A : 1.0
B : 2.0
C : <empty>
D : Apple

To trigger the error I set the slice node to generate a list of two consecutive keys. By changing the start index you can change this to A,B or B,C or C,D. I then feed the pair of keys into a lookup node and feed the results into a sting node.

KEYS : RESULT
A,B : 1.0, 2.0
B,C : Error
C,D : <empty>, Apple

Weirder still, for keys B,C, if I instead feed them into a First and Second node and then convert to strings, I get 2.0 and <empty> with no error. The error only occurs if I feed both values into the string node at the same time.

As a workaround I created a subnetwork called "safe_string". This subnetwork simply takes a list of values, slices them one at a time, and then converts each value to a string. If you hook the lookup node to the safe_string node, you get 2.0, <empty> without the error message.

Not a showstopper, but it sure was hard to track down.

John