Please share your Debugging Tips while scripting in GH

While scripting in GH I often use Dispatch and Panels to catch errors. For instance stop code from continuing if List sizes don’t match, values exceed a threshold.

When scripts become large it’s hard quickly to find the source of the problem. My current approach to catch and error is by setting color of a panel using MetaHopper.

While this works for me most of the times (Unfortunately this doesn’t not work within a Clusters.), I can imagine other methods for debugging are used within the community. Looking forward receiving your tips and suggestions
Error_Log Template.gh (8.6 KB)

Hello,

in my opinion, it’s all about separation of concerns and decoupling of logic. One group/cluster/script should follow one single purpose. To enforce “Single responsibility” sounds easy, but it’s actually very hard to achieve. We tend to mix logic for the sake of shortness and efficiency. If you decouple clearly, you can thread each part as a “black box”, meaning it’s not so important for you and others to understand how it works. It’s only important what has to go in, and what comes out. Basically the same as if you write your own component. Once you do that, you can create “assertion” logic for each “black box”, because you clearly expect data to come in and out in a more or less strict manner. The majority of errors I have encountered for definitions to fail are related to null items, to geometric-related failure (e.g. Boolean Union…) or because of dealing with wrong types (implicit conversion as a result of failure or wrong input in general). This essentially means, you should always check for null, for geometrical validity and making type checks. As a bonus, it makes sense to limit numerical parameters with bounds. Once you do that, you already prevent the majority of “Runtime” errors. Especially those, which tend to occur at other places!
Apart from this, the more you write directly by code, the more debugging and validations options you can choose. Nothing beats debugging by stepping through code! But this requires to write own components (as plugin)

Keep track of what is going into and coming out of every component!