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

Error: The ajax operation was aborted #49

Closed
bgentry opened this issue Jun 12, 2018 · 3 comments
Closed

Error: The ajax operation was aborted #49

bgentry opened this issue Jun 12, 2018 · 3 comments

Comments

@bgentry
Copy link
Contributor

bgentry commented Jun 12, 2018

If I leave my app running while the connection is unstable (perhaps on a Mac which is regularly sleeping) I see lots of these errors thrown from failed version checks:

Error: The ajax operation was aborted

These bubble up to my app's error handler and get reported to my bug tracking service. That's not ideal as I'd basically need to create a permanent exception for them so I never get notified about it. And also there's no real way for a user of this addon to decide what to catch vs. bubble up.

Maybe there's a higher level question here: which errors, if any, should be swallowed by this version notifier component, and which should bubble up to the app?

One possible interface to help with this would be an onError() closure input similar to the onNewVersion() that I just added. That might be the most flexible in terms of letting the developer choose what to handle.

Anybody have thoughts or other proposals?

@knownasilya
Copy link
Collaborator

knownasilya commented Jun 12, 2018

One possible interface to help with this would be an onError() closure input similar to the onNewVersion() that I just added. That might be the most flexible in terms of letting the developer choose what to handle.

I think that's the right solution.
If not specified we could just log the error, not throw.

@jrjohnson
Copy link
Contributor

I'm great with just logging connection and ajax errors or even swallowing them entirely. I can't envision needing to handle these myself, but if someone desires that then sure onError would be something to add later.

@bgentry
Copy link
Contributor Author

bgentry commented Aug 4, 2018

@jrjohnson sounds great to me, I don’t plan to do anything else with the errors for now but maybe somebody with a more advanced use case could add that if needed.

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

No branches or pull requests

3 participants