-
Notifications
You must be signed in to change notification settings - Fork 16
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
perform masks errors #63
Comments
This is exacerbated by the bare except in sync_wrapper that makes even raising SystemExit be insufficient. |
You probably want to be using Perhaps I should have made |
(also note the difference between |
Aieee. So, first step would be to make the docs steer me to the things you're recommending :) Secondly - I know twisted's model is to throw uncaught exceptions on the floor. I think this is batshit. Lets assume for the moment that it's desirable for perform to propogate unhandled exceptions. Do you think its technically feasible? |
Yeah, I think at the very least the docs should show usage of As far as having Basically since Effect supports both asynchronous or synchronous performers, it's explicitly designed asynchronously since that's the lowest-common-denominator. Then |
Can you help me understand why the async case can't raise errors? |
Yeah, sure. The problem is that most of the time (when things are actually asynchronous) the exceptions happen after Now that I think of it it may be feasible for |
So sure, if the error happens after perform returns, clearly thats hard :). But, if perform does achieve a final result - either because the outer most effect was sync, or the result was already available, then it could do it? That might make the distinction between sync_perform and perform less significant? |
yep. sounds good. It'll technically backwards incompatible because perform may start raising exceptions when previously it wasn't. My gut feeling is that it should be fine especially because very few people are using Effect so far. |
This is perhaps a usage bug rather than a bug in effect, but:
It seems reasonable to me that in the absence of a error catcher anywhere that it should ultimately propogate up to perform and beyond.
The text was updated successfully, but these errors were encountered: