I could think of various hacks to bypass this. For instance you can observe for windows poping up using user32.dll to close them automated. Another option is overriding default behaviour . At least Grasshopper is fully decompilable and therefore quite vulnerable for code injection/replacement.
This however is the wrong end to approach such problem in my oppinion. Actually catching errors on a superficial level is a good thing and shouldn’t be eliminated. Wouldn’t it be better to make a definition stable enough to not throw? What is causing this odd behaviour for you? If you deal with unpredictable computation time, then maybe some sort of precheck could warn you before even starting a heavy computation. Or maybe fully eliminating Grasshopper for static duties is another, much better option! In how many different definitions are you causing this error?
Just an example for using user32.dll: