.gha good error handling practices

I just finished my first couple of components, and after looking at the different examples and existing .gha components, I'm wondering what are good practices for handling errors.

I noticed that many of David's components bring up the GH_RuntimeMessageLevel.Error while the examples in the SDK often use "Return" to exit the component. I'm leaning towards the runtime message.

Any guidelines or thoughts?

And while I'm on the topic of error handling, any suggestions for catching an input file path that doesn't exist?

Replies to This Discussion

Permalink Reply by David Rutten on October 3, 2010 at 1:23am

Hi Benjamin,

the AddRuntimeMessage method only adds feedback. Your script still continues to run after you post error messages. If you feel that you're in a tight spot and there's no way out, you can safely return out of the SolveInstance method. You could also choose to assign empty, null, default or bogus values to the output parameters prior to returning.

I wish I had a good guideline for this stuff, but my components are unfortunately a bit inconsistent.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Benjamin Golder on October 3, 2010 at 1:42am

Thanks David.

I think I'll try to put in AddRuntimeMessage wherever it would help a user figure out what's not working. But I think I'm going to avoid returning out of the SolveInstance method unless I think there could be some bad consequences. This would tell the user that something's wrong, but let them decide whether or not they want the messy output.

Whether or not to assign other values seems like it would depend on how essential it was to maintain a certain structure, pattern or index in the output.

Permalink Reply by Damien Alomar on October 3, 2010 at 6:46am

Here's some general thoughts about this...

I've been using AddRuntimeMessage with a Warning whenever I want to communicate with a user. This is just about the only way the component can provide information about what's going on unless there's a dedicated "Out" parameter ala the script components.

To Me, an Error runtime message means that there has been a "fatal" flaw in the component. Something has happened, either internally or based on the inputs, that will not allow the component to do what it needs to do. I also think this means that there should be NO OUTPUTS for an Error. A potential reason behind this is that the user's attention needs to be drawn to the error so that it can be resolved. So by cutting off any downstream data, even if the user fails to realize there's a big red component with an error, trying to use its outputs downstream will not do anything and hopefully have them ask "what's going on here"

There inevitably winds up being some gray area between an error message and a warning message. As I mentioned above, an error message should only be used if there's a "fatal" flaw, and therefore you should be able to simply return after running into such an error. If there's still data that can be salvaged even though something has gone wrong, then I would raise a warning, and pass along as much data as I can.

@David...
I could see the value in adding a third message level of "Notice" that could be used when just providing relevant feedback. Maybe it could turn the component a light blue or something for indication. It just seams to me that three levels of messages might be useful. From "hey just so you know" to "There's something here you should probably take a look at" to "Something it majorly wrong here" (that would be "Notice", Warning, and Error, respectively)

Permalink Reply by David Rutten on October 3, 2010 at 8:17am

"I also think this means that there should be NO OUTPUTS for an Error."

Pretty good idea actually. I could nuke all components when it turns out they have at least one error upon solution completion.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by David Rutten on October 3, 2010 at 9:32am

Just added additional balloon feedback for runtime messages (also added an Info type in addition to Warning and Error). Eventually these balloons will show all the runtime messages via the Grasshopper tooltip.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Benjamin Golder on October 3, 2010 at 9:47am

YES. That is perfect. No more right clicking! Love it. And I love the Info type. Thanks David!

On the note about cutting off output in the event of an error, can anyone give an example of where this seems sensible? What kind of error warrants the redundancy or protection of having no output (as opposed to just the red warning signal with a messy output)?

Permalink Reply by David Rutten on October 3, 2010 at 9:54am

I think Damiens point is that when an error occurs, the predictability of the whole system goes down the drain. Trying to program in a chaotic system (yes, I believe Grasshopper is a programming language) is not recommended.

However, there are cases where errors are unavoidable at present, so I don't think I'll destroy any data just yet.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Benjamin Golder on October 3, 2010 at 10:01am

In the Local Code Project, when we were batch processing GIS data through Grasshopper, I would often have inputs that would cause errors, because the input data was so messy and sporadic. Sometimes, an error in one location would cause the definition output to shut down, even though I had built in alternative data pathways to accommodate such missing or messy data input. In this situation, I often knew there was a major error in the component, but didn't want it to stop the rest of the definition. It seems like checking for nulls, cleaning branches, and many other components can allow users to deal with potential bad output. So Grasshopper itself has many ways of handling errors.

Permalink Reply by Damien Alomar on October 3, 2010 at 10:25am

I don't think that its in the GH User's general interest for component Errors to get automatically nuked. However, I think that its something that anyone developing components should try and make sure that they don't pass any data when their components raise an error. Not that its the end of the world if they do, but I think it allows the problem to get pinpointed quicker. AFAIK there aren't any native GH components that will still pass data when an Error results, but I must say that I don't run into errors all that often.

Permalink Reply by Damien Alomar on October 3, 2010 at 10:20am

Awesome. Thanks David. Glad to see the Info type added. The balloons look good, but I could see them potentially getting really huge if there are a lot of warnings that pop up. So maybe they should be limited in size so that they don't take over the canvas.

Permalink Reply by David Rutten on October 3, 2010 at 11:57am

Hi Damien,

they don't resize. Messages aren't displayed inside the balloons, only inside tooltips over balloons. However I do think there could be too many balloons on the screen, so it will need a setting to only display warning and errors, or only errors, or nothing at all.

This is quite a departure from the GH UI framework as there are now more objects on screen that potentially occlude UI elements, it probably won't feel very fluent for a few versions to come.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Benjamin Golder on October 3, 2010 at 5:51pm

I don't know how hard these would be to implement, but ...
Maybe the component Icon could be replaced by an exclamation point or symbol, and then the tool tip over the component would reveal the runtime error message.
Or instead of a bubble, they could give off a colored glow. This would make it very visible but would allow all the components and wires to remain in the foreground.
While I'm dreaming, it would be neat if you could actually attach a colored glow to a specific input our output parameter by index when you raise the error, and then users could often see the problem without even having to read the error message.