C# - throw new Exception doesn't work for ScriptComponents

#3

Nope. It’s all on my internal drives.

(David Rutten) #4

I had a massive Windows update today, did you get one too?

#5

Not yet anyway. I could try restart to see what happens.

// Rolf

#6

No updates pending. I have 1803 since a few days back.

bild

// Rolf

(David Rutten) #7

The restart didn’t work then?

#8

No, I tried restarting, but no.

// Rolf

(Giulio Piacentino) #9

This is usually also the error message shown when an assembly is “Blocked”.
Right-click the file, go to Properties, and click “Unblock”.

Thanks,

Giulio

–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

#10

This is a ScriptComponent, so I don’t know which assembly to try to untick. In this case, saved as a UserObject, there seems to be no Unblock to do:

bild
bild.png516x541 22.4 KB

I don’t know of any references to any other assemblies either.

bild

Perhaps this is the good news, Microsoft no longer supports exceptions. Exception are dead? :thinking:

Cache Problems
BTW, there are more problems with the ScriptComponents; At one point an earlier Component.Message got “stuck” in the code, even if I removed the string assignment from the code altogether it still showed up, and obviously, the component ran older code than that which was visible in the editor. Only after a restart of Rhino the ghost code disapeared. Probably a cache problem.

Port Name Problems
Similar problem (cache) when modifying Inport or outport (Param) names. One has to add an extra new port, and then remove the extra inport (or outport), to get a new name to stick (to be compiled into the main signature), otherwise the default name remains (the x, y, z defaults, etc).

This last misbehaviour can be dealt with with a consistent workaround. Cached code giving strange execution results OTOH can be trickier to identify before wasting half a day on non existant bugs that are actual bugs, at least in runtime (old replaced cached code still in effect…). :nerd_face:

// Rolf

(Giulio Piacentino) #11

Hello again @RIL,

it’s not the .ghuser file. It’s a .dll or .gha from which that one depends that is blocked. Maybe KangarooSolver.dll, or another one.

Sorry, I cannot repeat the other two issues. If you keep on encountering them, it would be great if they were dealt with separately, in other threads.

(David Rutten) #13

Once loaded an assembly cannot be unloaded, and a script that is replaced by another script will still remain active. If it has no ties with the rest of the program it will eventually get garbage collected, but if it’s responding to events, yeah it’ll stay alive and running until the entire appdomain is unloaded, i.e. a Rhino restart.

I do run into this issue sometimes when writing scripts myself, basically there’s no mechanism in the SDK for telling a compiled script “hey you’re about to be replaced by a newer version, clean yourself up”. So you get these ghost assemblies interfering.

I did add RH-46167, it will probably help with detecting these cases.

(David Rutten) #14

That’s a bug that needs fixing. RH-46166

(David Rutten) #15

Based on your image there are no custom references to the script. The left panel is empty. So presumably one of the regular references is now giving problems. Which would mean you should also see that problem if you create a brand new script which does something trivial. Is that the case?

#16

OK, I betetr get used to my new ghost buddies then.

And some not too itchy bugs as well. As long as they are not grasshopper size I can deal with them.

I’l try again make a “trivial” C# script with only an exception call. bbs,

// Rolf

#17

I tried to make a simple sript, and there exceptions works:

bild
bild.png811x541 35.3 KB

So then there must be some “non-usual” assembly reference in the code that fails to throw the exception in the component attached. Do you get any exception? (it should, as long as the wire is not connected to the Num at the far right)

Forum - ExceptionFailure.ghx (105.9 KB)

// Rolf

(David Rutten) #18

Yes, the new component is red (huh error) the other one seems to work.

#19

The other one should be red too, as long as the wire is not connected (see row 171 and press Reset,)

(David Rutten) #20

Nope, it’s fine both with and without. Nothing in the Rhino command line, nothing in the runtime message menu.

This however, is a bug: if (m_current_result == double.NaN)

NaN are equal to nothing, not even themselves. You must use double.IsNaN(m_current_result) to test for nanity. Fun fact, the IsNaN method actually uses the equality comparer and returns true if the value isn’t equal to itself.

#21

After fixing this, it still doesn’t manage to display the error (which it actually catched earlier too, not oonly now), with the following message to the Rhino command line

Exception System.NotSupportedException:
Message: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

// Rolf

(David Rutten) #22

Oh yes, of course. You’re throwing the exception from within the solution end event handler, so it eventually ends up in the method that invokes all the handlers and it just swallows it. If you want to add a runtime error message to your component, then you must do so specifically by calling the AddRuntimeMessage method. Only within SolveInstance and RunScript are exceptions caught by Grasshopper and auto-converted into runtime error messages:

    if (double.IsNaN(m_current_result))
    {
      Component.AddRuntimeMessage(GH_RuntimeMessageLevel.Error, "Invalid downstream Fitness value");
      return;
      //throw new ArgumentNullException("Invalid downstream Fitness value");
    }
#23

Hh. Strange how I didn’t assume such a self evident thing! :wink:

Thanks for your patience.

// Rolf