Looking for a way to pass nothing

Hi all,

I’m looking for a way to pass… nothing!
My script has some part that may or may not calculate rebar and pass it on to the “Rebar.ByCurve” node.
If my script doesn’t get a value from excel I want to use an if statement that returns a standard value so I don’t get yellow errors. Or if there is a value from excel it uses that value to run the calculation and produce rebar lines.

For instance: I have 3 different rebar shapes using calculation method A for rebar shape 1, B for shape 2 and C for shape 3.
And from the excel file I only get data for shapes 1 and 3. But the calculation for shape 2 is present and will run and give me those yellow errors.
So to prevent the errors I want to feed the rebar shape 2 calculation fake data so it will run and produce a single curve with a vector. But also a result that returns nothing. Just like there is no connection to a node and turns the node light grey. Disabling the rebar.bycurve node so to speak.

Do I make sense and is this possible?

1 Like

I think this should help

Hi @erfajo,

when I pass a string like “dummy” to the inputs “curve” and “vector” from the node “rebar.bycurves” i will get an error that the input is not what the node is expecting.
I want to run my script in the Dynamo player so colleagues who don’t know about Dynamo can still use the scripts. But that means the script must run without any error else the user will think that the script didn’t do what it should do… dispite the fact that it did what it should do.

I’m looking for a way to freeze a node or that it isn’t doing anything.

1 Like

If you look in the link in my link it uses a code block and the node as a function. I think that will work.

1 Like

Hi @Steven,

you mean the .gif file that has the 2 ranges 0…5 and 0…10.
I’ve seen it but I don’t know if that is what I need.
Because that function is still passing on data. And it isn’t setting an other node into a function mode.
And to be honnest my knowledge of Dynamo is still to limited to see what a function as shown in that example can do for me.

This is what my script looks like when al calculations are needed:

In a code block I set up data that later will come from the excel file.
When a piece of rebar is needed the max. diameter is noted.
When it isn’t needed the excel cell will remain empty and return a “null” in Dynamo:
Rebar needed:

Rebar not needed:

And in this moment this is what will happen when the excel cell is left empty:
In the left green group of the red “circle” you see the calculation en on the right side of it you’ll find the rebar nodes)

I can certainly second this. never move a null/empty i you don’t have to and you certainly don’t have to here.

Instead try looking into creating some functions from the two possible routes and performing the function only if the value is null.

Yes I was talking about the gif. The first code block is running a list count is greater than X function. This produces a true or false depending on list length. You can use anything that produces a true or false (figure out what works best for you).

The second code block is where the magic is happening. Let’s say you have two functions one will err out depending on the data fed and one will not. The second code block will only apply the function (in this case multiply or divide) you want based on the true or false. It would be the same as plugging in the original list into the x input of the * or / nodes.

In my post sometimes I am going to end up with an empty list and the nodes will err out. This will allow me to bypass those nodes when an empty list occurs and no errs will appear. Like @erfajo said though without seeing your graph it’s hard to see if this will work for you.

@jacob.small and @erfajo,

I don’t like the fact that dynamo does not handle empty lists and nulls well. They are information and should work just fine being passed down stream. It sucks we have to go through such great lengths to avoid them like the plague.

Nulls and Empty lists can be frustrating. Unfortunately in many ways it’s a limitation of data types, not just a limitation of Dynamo. One example: computers (and life in general) can’t really perform mathematical operations on a string:
4 * “A” =
It makes no sense! There is no easy rationalized answer - “AAAA” is close but what happens if you divide? And what would “A”*“A” be?

For the same reason logic, you can’t perform functions on an empty list.

{} * 4 = ?

As far as nulls go, they should really only pop up when there is an error - it’s Dynamo’s way of stopping the process form going off the rails without stopping your graph entirely. Notice there is no OOTB way to put in a null - they are the warning you get when you multiple “A” by 4. It’s Dynamo’s way of informing you that the dataflow you’ve coded is broken at this point. Note that Python (and I believe other languages) do this as well. Think of it as a computer’s way of saying “HEY DUMMY! YOU DONE GONE AND TRIED SOMETHING STUPID!” but more politely. And once you’ve got a null value, you’ve changed data types - it’s not a string, nor a number, nor a cheesecake - it’s a null. You can’t do much with nulls - no useful functions anyway. Well other than “ask if it’s a null”.

But there are other ways. Like using a replace nulls node (there’s on in Clockwork, Bakery, Lunchbox in my order of preference), or a Code Block (my favorite method), or a host of other methods to resolve nulls and empty lists fairly easily. The key is you have to know to watch for it and plan around it - could someone have not yet put in that parameter? What if the sum of the numbers I’m using for the denominator is 0? What if BOTH the numerator and denominator result in 0? What if everything in that list is excluded?

The ‘easy’ way around this is to just limit your inputs - and this has been the ‘go to’ solution for ages. Go ahead and your calculator in windows and lean hard on the A key. No matter how many times you do it won’t do anything… Better yet, just find the A key on a TI85 calculator.

Once you play with them for a bit and understand the reasoning, thinking ahead to the ‘what ifs’ and finding ways around empty lists and nulls that pop up is often where I have the most fun. It’s a great opportunity to get creative or re-evaluate your workflow. I often find faster/better ways to accomplish what I was after at these points (ie: Nesting a function in an if statement, or going in another direction and doing something completely different).

I’d be curious to hear @erfajo’s take on the subject.



I understand that in some cases a null or an empty list is a mistake but in many it’s not. In my example link I posted I was trying to replace Items at various indices if a particular event had taken place. If this event does not exists an empty list is returned for indices that need to be replaced. If I feed an empty list into the index input of List.ReplaceItemAtIndex that should mean I have no items to replace and the input list should be returned but instead I get a single empty list. I now know that I can run this as a function but that seems like a much more complex way to go about it.

In the image below I used String.ToNumber with the intent of getting nulls. I needed to find strings where the second item was a number. The node still works and passes the information but after each run I checked the whole graph to see if an actual warning had accrued or if it was just String.ToNumber.

I guess it could be nice to have the option to turn off null warnings for some nodes. When you first make the graph it pops up to let you know there are null values being created and if this is expected you can then choose to ignore them.

1 Like

Smart alecking aside, these are all very good points in how languages are designed with nulls in mind. I think the difference in DesignScript vs another language that you pointed out like Python, is exception handling. So when nulls are thrown into the script, either by mistake or by error raising, Python can handle it but Dynamo still doesn’t have a very intuitive way yet, besides knowing more in-depth DS.

Granted, try-excepts are not meant for novice users like my self and are not best practice but in a pinch could be used effectively.


@kennyb6 - That pic just made my night!

If you ask me, Python doesn’t really handle null any better than Dynamo or most other laungauges do natively - they both just pass the null on and on and on the same way design script and nodes will. If it happens in any language it’s a problem and needs to be dealt with.


The string to number is a good example actually - I’ve used it returning as a test before, similar to what you showed. The fact that it returns null actually is a good thing there though - if it didn’t you’d have to think up something else.

I know it’s a bit more work, but wanted to point out that if you ask for the null in a test in a code block you don’t have to go back and look for other errors. By creating the null and asking if it’s null you avoid the warning. Well, oftentimes you do anyway…

Sorry I guess I should have meant that Python handles errors from nulls better than Dynamo, rather than the null itself. Dynamo doesn’t have ootb nodes for error handling, it just shuts down where it happens. Python has more capabilities. Interestingly enough, @john_pierson used a python script in this post with try-except to handle nulls when trying to get value. In the case that the value returned would be a null/error, he could return something different. When trying to do that in Dynamo, as far as I know, no OOTB node can handle it, aside from DesignScript.

Your original points still stand though that nulls are errors and that nulls are not supported as is in most languages. Python can handle the errors from the nulls but not the nulls themselves.


I think this is the problem (for me at least). I know visual scripting quite well now been using Dynamo for almost 2 years and grasshopper for 4. I can read code but it’s not intuitive for me to wright. So taking the time to imbed the tasks inside of a code block would take much longer than just checking the graph after. Thank you for the example it does really help me understand how to wright it since I know the problem. I am slowly trying to learn how to write code.

Grasshopper though (where I started) has no problem with nulls and so I have come accustom to using them. I think this was one of the hardiest things to overcome in my transition to dynamo.

The post @kennyb6 linked is a different part of the example I sheared above. John used the try-except to return an empty list if the script could not retrieve a tag heads location. He did this so it would keep the list structure as the graph continues. In the case of empty lists being returned I would filter them out or change the input before moving on but without it the input and output data structure would not match.

I can understand that they are an err but it sometimes feels like dynamo looks at nulls and empty lists more as an unforgivable sin than a mistake.

The transition from noder to coder takes a bit and you have to be persistent and not give up. The single best tool for this is the node to code functionality - highlight some nodes, right click the back ground, and you have a single code block that has all the outputs and functions of the nodes. This is the simplest way to start the transition. After a bit you’ll be like me - struggling to only use nodes when building example graphs to show to a beginner. It took three tries to get me to back out of the code blocks on a recent example I built for a presentation…

I don’t have much experience with grasshopper, but as I understand it Grasshopper works with trees not not nested lists, which is likely part of why it ‘soldiers on’ the way it does. I’ll ask around and see if I can find out more though.

1 Like