This could greatly improve the way to deal with cases such as this one:
Part of themodel can be toggled in or out, but its creation is a succession of GH Components. In this case, many of the components don’t take Null as a valid input and return an error. For now our way to deal with that is with multiple Stream Filter components but this seems suboptimal. Having a try catch error, we could put all the component creation in the try error and have some sort of Null geom in the catch.
Other dvantages could be:
Deal with blocking red error in rhino compute → In this case i guess errors situated inside a Try condition should have a different behaviour.
Have a by default behaviour when having multiple configurations
I’d be glad to hear your thoughts about that (or if such a component exists and i’m missing it)
Yeah i am aware of that but when i want to toggle off a whole component it usually implies having multiple Stream Filter components, one for each component that may fail. Having a try catch system could enable a more global way to tackle this kind of situations.
Plus, this kind of red errors is blocking in a compute context.
I would even say the opposite. In most cases you want to stop the execution as soon as an error is detected. Grasshopper isn’t even strict enough in my opinion.
Its almost never good, if you allow the null state downstream. Even worse is if you swallow the error and pass down an arbitrary replacement value. You might not even detect the actual problem. What is meaningful replacement value? A zero point, a point with NaN or a point with Min-Values? A zero point could be a legit coordinate, which often is set in a model…
Try-catch in the programming context, is usually a mechanism to prevent hard crashes and to deal with an error-prone operations (e.g. when opening a socket or doing IO operations). However, using it excessive, is an anti-pattern. Part of the reason is the effort to properly handle the error. Of course there is no black and white, and there are occasions where it might be useful, but giving the ability to over-use it will lead to bad definitions.
I think what would be more helpful is a way to branch definition more easily. What I find most obscure, is that GH has no if/else component. Sure there is dispatch, filter, eval etc, but @innos approach is actually a good way, because it exposes the error and still prevents the application from stopping.
I get the fact it’s not best practice, and you’re right about the fact an if/else component would make much sense as well. In the end i think we just need a way to “block” an entire branch so that it doesn’t get an error (if it isn’t fed with some components for example).
Also, the fact that this is a big deal for us comes from the fact that in compute red errors prevent the server from returning anything (see topic here as mentioned before), which is not the case in the GUI.
One of the worst issues I traced down is all about receiving lying or swallowed error messages. So I’m very aware of the downsides of try-catch …
Anyway. Yes this is unfortunate. I think the only solution you can realistically apply in this case is preventing the error from occurring. This means to filter out invalid input of your component groups, create conditions where geometrical errors can simply (almost) never occur (proper surface/mesh data for intersection etc.) or by preventing the use of quality-of-life components which do more for you than required. It can help to script those components which are notorious for causing error and maybe perform a try-catch on code level.
I doubt there will be an official try-catch component, and plugin developers would need to apply quite advanced hacking techniques to defeat the default error mechanism.
…