Rhino.compute breaks from grasshopper exceptions


I’m using rhino compute to run grasshopper scripts but I’m running into some problems with the error handling. When I run my script in rhino desktop it works fine, but there are some warnings and even a few exceptions. However, this doesn’t affect the output result from the scrip - it still returns what it is supposed to when I run it in the desktop version. I would like rhino compute to just ignore all warning and exceptions and just continue to execute the script just like in desktop. Do you know if this is possible or have any suggestions for a workaround? Thanks a lot! @fraguada @stevebaer

The response status code will be 500 if the definition has any errors.

The results are still included in the body of the response, but the client may not be making it easy to get to the results.

How are you making the requests to Compute? Are you using one of our compute.rhino3d libraries?

Hello Will!

Thank you for your reply!

How are you making the requests to Compute? Are you using one of our compute.rhino3d libraries?

We are making a fetch request from the appserver to /solve in the following way:

const response = await fetch('http://localhost:3002/solve', request)
console.log('Response: ' + JSON.stringify(response))

When we get a 500 error, the response object only contains message and stack, but no values.

We have investigated what might cause the error by making two copies of the same script, one that always raises an error and one that does not. In the version with the error we added a zero division in a python component outside the main dataflow from the RH_IN: to RH_OUT: parameters to be sure that the error should not compromise the output data. This means that the the main dataflow should not be affected by this error.

Do you have any suggestions on how to continue the debugging for this error?


Here is the file that we use for debugging as well if that’s helpful.
The problem is that we cannot find the body of the response string from the fetch request.

error_test.gh (12.4 KB)

I just wanted to say that the issue is resolved. I found this topic

with a similar issue. I guess I didn’t really understand what you meant before @will but after reading your comments on that thread it became more clear. Thanks a lot!


Thanks for the update and sorry for not responding.