Figuring out a problem concerning: if,else,list and constructing a plane

So what is the case. I have the following rules that I have to follow:

And I have made a couple of lines of script. In theory It should work but this is only the theory. My target is that on the point lists that you see in the left gh component I make planes.
The points and the planes construction follow the same IF, ELIS logic. the problem is that for some reason I am unable to make the plane. The error is:

The script is that:

import Rhino.Geometry as rg
import math

len = btAx.GetLength()

if len<1200:
#var 1
a = rg.Plane(var1, hNBv, mAx)
rg.Plane.Rotate( a , math.radians(-90) , a.YAxis)

elif 1200<len<1800:
#var2a
a = rg.Plane(var2a, hNBv, mAx)
rg.Plane.Rotate( a , math.radians(-90) , a.YAxis)

elif 1800<a:
#var2b
a = rg.Plane(var2b, hNBv, mAx)
rg.Plane.Rotate( a , math.radians(-90) , a.YAxis)


Runtime error (ArgumentTypeException): expected Point3d, got NoneType

Traceback:
line 14, in script


I honestly have no idea what is going on. The lists are made of 3D points…

Thanks in advance for the help :slight_smile:
problem.3dm (679.2 KB)
problem.gh (8.8 KB)

Hi,

To prevent ‘empty’ point lists from raising an error when trying to use it as an origin, you can test for them being truthy:

I do see another issue for lengths that are exactly 1200 or 1800, you need to add = sign on either side of the tests:

HTH
-Willem

1 Like

Hi,

so now we enter into the really unclear for me part. How do I prevent that? What does “truthy” mean in jargon? :slight_smile:

The list should have empty parts because in the first gh component they don`t meet the requirement.

not sure about the logic here.

I’m not sure how to best handle this in GH you will have to await others to chime in.

As for the truthy part:
It’s a term that describes if and how a value or variable will behave when tested for being True or False

You either accept null/none or empty input, or you don’t. I’m not a big fan of allowing data to be in (partial) null state, and I believe it’s better to get a null exception as soon as it occurs. The big problem with null states is that they are passing the error to another location. Imagine 10 components later having an issue because something was null. It’s not quite obvious, why and when this issue occurred. You are always hunting it back down to the place of occurrence anyway. What you can always do is to check for null/none states and to raise a more descriptive error message then. Because if you do it like Willem, you are just ignoring the fact that something is null and indirectly hide that there is a problem. You later just wonder why something in your baked model is missing. If you accept that something is null, you should at least create a warning!
If it’s about maintaining the tree structure, then you rather use remapping techniques and only apply the operation being applied on valid data.

1 Like

So a little update here.

I am not sure that this is the correct way I actually am almost certain that this is the wrong way to approach this. If I make the lists here flattened the error disappears.
image
which is nice :)/
But then it turns out there is no plane to be seen at all :slight_smile:
in theory, there should be planes all over the place :smiley:
image