[Rhino6] LayerIsVisible error shown as messagebox instead of exception

When calling Layer.IsVisible on a child of which the parent has been turned off, a messagebox/dialog is shown, rather than an exception being thrown. This sort of messes up any kind of error handling that you may want to do programmatically.

I would argue that changing a property should never trigger a messagebox.

Is this because I’m doing something wrong, or could this qualify as a bug?

Using Rhino 6 - latest stable release.
Minimum example to reproduce behaviour:

RhinoDoc.ActiveDoc.Layers.CurrentLayer.IsVisible = false;

I agree, that throwing an exception makes more sense for handling errors.

BUT:Turning the current layer invisible is not allowed in the first place. The only way this should be able to happen is by user interaction, because your line of code is invalid and should not even be attempted.

Does the messagebox appear if you try to turn any layer invisible that just happens to be the current layer?

It also happens if you try to turn on a layer which parent is turned off.

It should not happen - agreed. But if you somehow mess up - you throw exceptions. Exceptions are the way to handle errors, and messageboxes will halt the script untill someone will press ok. This is consistent with how errors are handled in the rest of RhinoCommon.

There’s a whole lot of different things going on here.

First of all, Exceptions usually break the code and are not some sort of nice way to handle everyday decisions.

If you try to hide several layers, make sure none of them is the current layer. If you try to change the state of a child layer, make sure to check the parent first. It’s simple. Things like that may be not the most useful cases for you, but they are common. They can be checked and handled in your own code.

Exceptions should be thrown in case of an actual error. You can handle the error, log it or bring it to the users attention. But generally speaking, your code should not expect to run normally after an exception. It’s true that minor cases can be ignored. Exceptions even can be made good use of like when you try to access a resource, you cannot be sure is available. But that’s no excuse to misuse exceptions as replacement for a simple if-clause.

Of course I can make sure this case does not occur. It’s just that messageboxes are a very naughty to way expose errors in a public API.

But generally speaking, your code should not expect to run normally after an exception.

This is baloney.

Hi @arendvw,

I agree. You are seeing the message because the internal layer table doesn’t allow the current layer to be turned off. The RhinoCommon property you are calling should check for this.

However, since most RhinoCommon developers aren’t much for catching exceptions, I vote for just not setting the property (and thus suppressing the message box).

https://mcneel.myjetbrains.com/youtrack/issue/RH-48321

– Dale

However, since most RhinoCommon developers are much for catching exceptions, I vote for just not setting the property (and thus suppressing the message box).

Fair enough. Supressing the messagebox would work for me.

Although I can imagine that the magic going on in this property could also justify a method rather than a property. Some very low priority thoughts on how to improve the API:

  • Settings the IsVisible property on a parent layer will also recursively change the children to visible. (A bit more magic than might be expected from changing a property). A method SetVisibility(bool IsRecursive) with a boolean flag for ‘recursive’ could help discoverability of this behaviour.
  • Settings the IsVisible property on a child layer which parent is not visible will not recurse up the parents, and give an error.
  • So the workflow for only turning on one child layer without it’s siblings means first turning on all parent layers, then recursively disabling all their children, except the one you wish to show. This is a little bit frustrating (but workable none the less).