Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix error handling within iterator #362

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

buddly27
Copy link

@buddly27 buddly27 commented Mar 8, 2020

This resolves #353

Tested with PySide2 and Python 2.7, Python 3.7 and Python 3.8 with the demo window:

python -m pyblish_qml --demo --targets default

(took me a while to figure out that I had to pass the 'default' target to see something!)

I didn't deal with unit tests as I am unfamiliar with nose, please let me know if you want me to handle it.

When no error message needs to be passed, use 'return' to exit the
generator as recommended in PEP-479.

When an error message needs to be passed, raise a RuntimeError exception
instead to ease the data flow. No need to catch exception in the
iterator as we will deal globally with exceptions raised at higher
level.
The logic within 'util.defer' is catching all exceptions and emit it
as a result without discriminating between finished tasks and errors.
Therefore we could simply check if the result is an instance of
Exception to figure out if the process should exit.
Copy link
Member

@mottosso mottosso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this, there are a few things I suspect might cause issues, have a look at my comments.

pyblish_qml/control.py Show resolved Hide resolved
pyblish_qml/control.py Outdated Show resolved Hide resolved
pyblish_qml/control.py Outdated Show resolved Hide resolved
pyblish_qml/control.py Outdated Show resolved Hide resolved
Using try-catch to transmit error messages from the iterator to the
process callback would be nicer, but some issues remains:
- It doesn't account for non-error messages (e.g. "Stopped")
- It doesn't discriminate between error which should be caught and error
  which should raise.

Therefore it is simpler to keep using StopIteration to exit the iterator
while transmitting messages to display, and change the syntax to conform
with Python 2.7 (No 'return' with argument allowed inside generators)
and Python 3.7 (generators shouldn't raise StopIteration).
@buddly27
Copy link
Author

buddly27 commented Mar 8, 2020

I reverted to using the logic suggested in #353 (comment).

Removing usage of StopIteration would require more thoughts to prevent the issues you highlighted.

@mottosso
Copy link
Member

mottosso commented Mar 8, 2020

(took me a while to figure out that I had to pass the 'default' target to see something!)

Do you mean that just calling python -m pyblish_qml --demo isn't enough to see anything, that you also need --targets default? :O That shouldn't be the case, might be a bug.

@buddly27
Copy link
Author

buddly27 commented Mar 8, 2020

Do you mean that just calling python -m pyblish_qml --demo isn't enough to see anything, that you also need --targets default? :O That shouldn't be the case, might be a bug.)

Yes that's what I mean. I guess it could be because targets default to ["default"] in pyblish_qml.host.show, but not in pyblish_qml.ipc.server.pyblish_qml. Though I feel default targets should probably be handled by pyblish-base instead for a better separation of concern between UI and logic, don't you think?

if not targets:

kwargs["args"].extend(targets)

@mottosso
Copy link
Member

mottosso commented Mar 9, 2020

Yes that's what I mean.

Can confirm this is happening, it happened in the latest release 1.11.1 and works as intended in 1.11.0. I've pushed a fix for it now.

835bf3b

That's beside the point in this PR however. Let me know when you're ready for another review.

@buddly27
Copy link
Author

buddly27 commented Mar 9, 2020

Can confirm this is happening, it happened in the latest release 1.11.1 and works as intended in 1.11.0. I've pushed a fix for it now.

Thanks!

Let me know when you're ready for another review.

Ready now :)

@buddly27
Copy link
Author

Just merged back latest change to this branch, let me know if there are any issues still!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

'return' with argument inside generator
2 participants