-
Notifications
You must be signed in to change notification settings - Fork 1
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
Stopping progress propagation #2
Comments
Mine as well. No strong feelings, but that seems like the right path. |
Yeah, it seems like if our options are only return or throw, implementations have to to "corrupt" one of those code paths with logic that checks for the stop propagation value. If we allow both, implementations have to execute that logic in both paths. I'd rather corrupt the exception path :) It's also a decent analog to throwing |
The analogy is a bit strained since |
Yeah, more that the approach of using Hmmm, that does make me think, though, that maybe an Error with a To my eyes: if(result && result.stopProgressPropagation) is nicer than if(result && result.name == 'StopProgressPropagation') Thoughts? |
Meh, I weakly prefer the |
I prefer if(result instanceof Error && result.name == 'StopProgressPropagation') |
See #1
Progress handlers should be allowed to explicitly stop progress propagation. The trend in #1 seems to be toward allowing handlers to throw a duck-typed "stop propagation" error.
What should this error look like? One option is to follow builtin Error convention and have it be an Error whose
.name == "<some specific name>"
, since we can't rely oninstanceof
across implementations.Two related questions:
My instinct is that we should only support throwing the stop propagation error.
The text was updated successfully, but these errors were encountered: