Trap mistake of executing workflow while still open in KNIME GUI
applio opened this issue · 1 comments
The often innocent but common mistake of attempting to launch a KNIME workflow via knimepy while that workflow is still open in the KNIME GUI is not as easy to recognize as it could be.
Making this mistake (launching an already open workflow via knimepy) currently results in an exception as expected. The captured stderr (made available through knimepy currently) does also contain the error message from KNIME objecting that the workflow is locked by another KNIME instance. But this requires the user to read through the somewhat jumbled output captured from stdout/stderr to find the one line explaining this.
The proposal is to specifically trap this error condition and raise a more communicative exception that highlights the cause (workflow is locked by another running KNIME instance).
While there are many potential situations where we could consider custom traps for different known stderr messages, this particular situation perhaps occurs more frequently than any other cause of failed workflow executions from knimepy (at least based upon the number of reports on forum.knime.com).