Feature Request : Compute debug / error messages improvement


When using compute in development, most of the time the dev experience is somehow trial and error. For example, those kind of error messages appear often :

  • ‘Object reference not set to an instance of an object.’
  • ‘GH - Missing Definition Objects’

Would it be possible to add a way to identify which component returned such an error ? It can be really timeconsuming to figure out this manually. Also, when components are missing (for example a library has a different version, or is not installed on compute server), can we get a meaningful message that states what is the name of the concerned components ?

What do you think ?

Thanks in advance

1 Like

Hey @Laoky ,

That sounds frustrating. Can you let us know a little more about your setup, IDE etc, and possibly even share some code we can use to replicate these kinds of errors? I’m hoping I can help you uncover more useful debug info.

Hi Callum,

Thanks for the reply. I am not sure I can actually post any code or IDE setup as I am using compute with Hops. I should have stated this in the first post.

Can you share something I can use to replicate your issue so I can see it for myself?

@Laoky So more information about the errors (e.g. stack trace) dumped to the terminal where compute server is running?

Yes, absolutely.

What would help also is a way to find a given component via its GUID. Sometimes, when you have several identical clusters and one of them has issues, there is a GUID printed in the console. But it’s actually not really useful for the user, as we still don’t know how to identify the faulty component, from its GUID (at least I don’t know how to do it). I can try replicating some of those printouts if it helps.

Here is one example :

I get 2 errors displayed in the console.
Only 1 is shown on the Hops bubble.

Here it is in the context of ggIFC library troubleshooting. This library actually shows where in the code the error lies. But there is not extra layer of information (I would expect some) at the compute level or grasshopper level that states which actual node was faulty. It’s maybe because of clusters (I see the 2nd error that actually contains more information is at the root level of the gh definition).

See how the information about errors is hard to find for the 1st error, I have no idea as a developer where in the definition it happened.

I will keep on posting examples of such situations if you don’t mind.

Hi Loic. I agree that logging information could be much better. And you’re right, we should include more information about what component is failing (other than just the guid). However, I just tried to create a simple example and from what I’m seeing in this particular example, the component name is being returned (see below). Do you have a simple example (which does not use a 3rd party plugin) that I could test and hopefully fix with additional information?

1 Like