RunTime messages on exceptions in compiled VS C# grasshopper projects

Hi all,

How do you set up your VS project to allow for stack trace including file names and line numbers in the runtime messages on GH components in case of exceptions?

I see that the Clipper plugin has more detailed exceptions than usual, but I cannot find any special exception handling in the plugin. Must be some compile setting?


it is rather a matter of how you deal with exception handling (and if you want to expose the user to the stack-trace). You can run anything in one (top-level) try-catch block and just catch any exception from your code. Then you re-throw the exception with the exception stack trace to be caught by Grasshopper. If you only want this to happen in Debug mode, you simply wrap this try and catch in a #if Debug preprocessor directive.

Besides this, you can also attach to the Rhino process and directly debug your code using breakpoints. Therefore, press Ctrl-Alt-P in Visual Studio and select the running Rhino process.

Ahh stupid me, you are completely right.
It was right there in front of me.

 catch (Exception e)
                AddRuntimeMessage(GH_RuntimeMessageLevel.Error, e.Message + ": " + e.StackTrace);
1 Like


Rhino inside Revit also has a pretty extensive exception handling in their components, for reference:

How you handle errors is really up to the type of application you build.

In general, you want a try-catch on the top-most places and/or at the places where the user interacts with your code. Usually the user is the one who is breaking your system. Sometimes you need nested try-catch blocks, for instance if you need to free/dispose on a failure. But in general, you want to avoid nesting.

For GH plugins, the topmost place is the same place where the user interacts with your code. So it is quite easy, it’s the SolveInstance/RunScript where you want to try-catch (Unless you do also some dangerous initialization when the user drags your component on the canvas, or you inject some views.).

Usually for an average custom component its not super dangerous to not try-catch, because Grasshopper and Rhino also try-catch. If not, Rhino would crash whenever there is an exception.

1 Like

Maybe one more thing to know when or where to place a try-catch block.

A good error handling system will bring the system back into a state where the system can run normal once an exception occurred.

E.g. On a command-based system, the running command should terminate, no matter if successful or not. It ideally should not change the system to a state where you cannot run commands anymore. If this happens, the app has to terminate, otherwise the exception is logged and the system runs as normal as it used to be. You can however also use try-catch blocks to handle alternative paths of your code. But the tricky part is when you encounter critical exceptions. Some exception might indicate that the integrity of your system is harmed, therefore they most resolve correctly. Catching them in the wrong try catch block might lead to a situation where the app runs in undefined behavior. Therefore it makes sense to only catch for specific exceptions in your nested try-catch blocks or that specific exceptions are rethrown. In any case nesting makes it difficult.