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

reduce sync io, only ignore foreseen errors #234

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hulkish
Copy link

@hulkish hulkish commented Jan 29, 2019

  • fs.existsSync preceding a fs.readFileSync is 2 sync io operations that can/should be 1.
  • in browser, makes sense to ignore all errors for xhr reqs
    • but, in node - only anticipated (ENEONT) errors should be swallowed
    • for example, it would be bad if EACCESS is swallowed.

@@ -88,12 +88,14 @@ retrieveFileHandlers.push(function(path) {
if (xhr.readyState === 4 && xhr.status === 200) {
contents = xhr.responseText;
}
} else if (fs.existsSync(path)) {
} else {
Copy link
Author

@hulkish hulkish Jan 29, 2019

Choose a reason for hiding this comment

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

both usages of fs.readFileSync are already inside a try/catch block, it's safe to just let them try the read - a missing file error (ENOENT) gets swallowed anyway

Copy link

@evenstensberg evenstensberg left a comment

Choose a reason for hiding this comment

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

lgtm!

@LinusU
Copy link
Collaborator

LinusU commented Feb 12, 2019

Hmm, I wonder if this should be a breaking change or not 🤔

What do you think? It might throw now when it didn't before...

@hulkish
Copy link
Author

hulkish commented Feb 13, 2019

@LinusU I can understand if that's what is decided. Though, personally i view this as a fix.

@hulkish
Copy link
Author

hulkish commented Feb 14, 2019

I suppose on principle alone its always better to play this safe... Basically this could "break" downstreams since all errors were being swallowed, before. Though, i would argue this would be a legitimate break - but probably better to release as major bump

@hulkish
Copy link
Author

hulkish commented Jun 4, 2019

@evanw thoughts?

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.

None yet

3 participants