We get lots of posts with run time error messages that look like
How can we extract useful information from error messages like that?
Here's how:
The name of the block is in the error message, between "The operation" and "cannot".
In this case, the operation is "select list item".
To proceed further, we need to look at a sample of that type of block, to see what it wants as arguments (the stuff that goes into its sockets.)
This sample was pulled out of the Builtin List Blocks pallette, empty, but with its argument names on the right:
- list
- index
Notice how there are the same number of arguments in the error message (wrapped in [...] and separated by a comma) as there are sockets in the block type in question. They should match in the same order. I drew red lines in my annotated sample to show how they match.
Now we have to go through the arguments and see how they satisfy the expectations of that block, based on the argument names (list and index).
Let's do the second (index) first, because it's easier.
We have a 1 for the index.
Indexes in lists are supposed to be numbers, starting at 1, so that looks okay.
Now let's look at the first one, the harder one.
The argument name is "list", so we had better be feeding the block a list.
But look in the first item in that error message, and what do we see?
"Penguin.jpg"
Notice the " around the text? That tells us it is a piece of text, not a list.
If it were a list, it would be formatted with an extra layer of [...] around it (assuming you stuck with JSON style list formatting in your Project Properties.)
Likewise, if it were a dictionary, it would be wrapped with {...}.
When a block complains about its arguments, that might be because of two reasons:
- a wrong data type (like math blocks that choke on empty text), or
- a data value out of bounds (like divide by zero.)
So when you read the error message, compare the values and types of the arguments against the expectations of that block.
Once you have identified the place where the error occured, and what was feeding the error, it is time to trace back the incoming data.
Where did it come from?
Who or what set its value, and when?
Read your code surrounding the errored block backwards and look for footprints in the data, like a detective.