tests/ui-smote/qtdragon-quit consistently fails on F43

[BsAtHome]

The new test for qtdragon-quit fails consistently on Fedora 43. In the logs a message is found:
...SyntaxWarning: 'return' in a 'finally' block.

This is probably the same issue as #4075. Fedora 43 is on python 3.14.5 and may be a bit more critical what it accepts.

Applying the following diff makes the issue go away (like what was done in #4075), but I have no idea whether this is the right fix.

diff --git a/lib/python/qtvcp/qt_action.py b/lib/python/qtvcp/qt_action.py
index 3952200bda..afe02a62b8 100644
--- a/lib/python/qtvcp/qt_action.py
+++ b/lib/python/qtvcp/qt_action.py
@@ -394,7 +394,7 @@ class _Lcnc_Action(object):
                 outfile.close()
             except:
                 pass
-            return npath
+        return npath
 
     def SET_AXIS_ORIGIN(self, axis, value):
         if axis == '' or axis.upper() not in ("XYZABCUVW"):

@grandixximo Please have a look.

[grandixximo]

Yes, that is the right fix.

The return npath was inside the finally block. Python 3.14 warns on this because a return in finally silently overrides any pending return or exception, which is almost always a bug. Here it actually was one: on a write error the except branch runs return None, but the finally's return npath clobbered it, so SAVE_PROGRAM returned a valid-looking path (and swallowed the exception) even when the save failed.

Dedenting return npath out of finally to the method body fixes both:

• success: try succeeds, finally closes the file, then return npath
• error: except returns None, finally still runs to close the file, None propagates correctly

So this both clears the SyntaxWarning and restores the intended error semantics. Same approach as #4075.

I also walked all of lib/python for return/break/continue inside finally blocks; qt_action.py was the only remaining occurrence, so there are no sibling cases to chase.

Gotta love a language where a one-character indent shift is the difference between "saves your file" and "lies about saving your file"...

[BsAtHome]

There seems to be a race-condition in the qtdragon-quit test. It still fails regularly. There is nothing obvious in the logs. Running the test again then passes. Very hard to figure out what is wrong. However, the initial fail is often followed by consistent success. That could mean a startup timing race problem when not all code/data in the cache.