Expand the circumstances under which we expect the C++ object to be g…

…one.

This was uncovered after caching, but might've existed before; that extra update function that's now within the try could _also_ call the emitters, causing the same problem for which the existing try-catches where made.

CURA-12190

UM/Settings/Models/SettingPropertyProvider.py

@@ -363,16 +363,16 @@ def _onPropertiesChanged(self, key: str, property_names: List[str]) -> None:
                 # logic to emit pyqtSignals is gone.
                 return
 
-        self._updateStackLevels()
-        if has_values_changed:
-            try:
+        try:
+            self._updateStackLevels()
+            if has_values_changed:
                 self.propertiesChanged.emit()
-            except RuntimeError:
-                # QtObject has been destroyed, no need to handle the signals anymore.
-                # This can happen when the QtObject in C++ has been destroyed, but the python object hasn't quite
-                # caught on yet. Once we call any signals, it will cause a runtimeError since all the underlying
-                # logic to emit pyqtSignals is gone.
-                return
+        except RuntimeError:
+            # QtObject has been destroyed, no need to handle the signals anymore.
+            # This can happen when the QtObject in C++ has been destroyed, but the python object hasn't quite
+            # caught on yet. Once we call any signals, it will cause a runtimeError since all the underlying
+            # logic to emit pyqtSignals is gone.
+            return
 
     def _update(self, container = None):
         if not self._stack or not self._watched_properties or not self._key: