Skip to content

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Jun 20, 2017

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

buffer

@jasnell jasnell added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jun 20, 2017
@nodejs-github-bot nodejs-github-bot added buffer Issues and PRs related to the buffer subsystem. errors Issues and PRs related to JavaScript errors originated in Node.js core. labels Jun 20, 2017
lib/buffer.js Outdated
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo

@Trott
Copy link
Member

Trott commented Jun 20, 2017

lib/buffer.js currently has 100% code coverage in our test suite. If not too onerous, it would be nice to run the coverage report on this PR to make sure the refactoring doesn't introduce code paths that are now untested.

lib/buffer.js Outdated
Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer using buf1 instead of a in the code as well.

Copy link
Member

Choose a reason for hiding this comment

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

Would { FastBuffer: undefined } make it more self-documenting?

Copy link
Member

Choose a reason for hiding this comment

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

Alphabetical order.

@jasnell jasnell added the wip Issues and PRs that are still a work in progress. label Jun 20, 2017
@jasnell
Copy link
Member Author

jasnell commented Jun 20, 2017

Forgot to mark this as in progress as I still need to add the documentation updates for the new error codes...

Copy link
Member

Choose a reason for hiding this comment

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

Maybe call the error type something more generic? There could be any variable that may not be negative or that may not be greater than x.

Copy link
Member

Choose a reason for hiding this comment

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

I am not sure if the error codes should be more generic or not but I think it would make sense if they are. In this case the ERR_INVALID_OPT_VALUE type could also be used as such.

Copy link
Contributor

Choose a reason for hiding this comment

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

IMHO including the encoding name is better.

Copy link
Member

Choose a reason for hiding this comment

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

See my comment below. This type is at least redundant to ERR_UNKNOWN_ENCODING but I would use ERR_INVALID_OPT_VALUE instead.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if these types would only fit for buffers and therefore I recommend to remove the BUFFER part from the name.

Copy link
Contributor

Choose a reason for hiding this comment

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

There's the whole over specialization of invalid options debate:

try {
  // do some stuff
  var f = fs.openSync('g.txt', 'rgh');
  // do other stuff
catch (e) {
  if (e.code == 'ERR_INVALID_OPT_VALUE') console.error(e) && process.exit(1) // because it's a programming error
  else ...;
}

Maybe worth creating a new type? OptionError, or have all the codes include a substring?

Copy link
Member

Choose a reason for hiding this comment

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

This could be consolidated with ERR_ARG_OUT_OF_BOUNDS even though it's not as specific.

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

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

Overspecialization of error codes should be discussed

Copy link
Contributor

Choose a reason for hiding this comment

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

There's the whole over specialization of invalid options debate:

try {
  // do some stuff
  var f = fs.openSync('g.txt', 'rgh');
  // do other stuff
catch (e) {
  if (e.code == 'ERR_INVALID_OPT_VALUE') console.error(e) && process.exit(1) // because it's a programming error
  else ...;
}

Maybe worth creating a new type? OptionError, or have all the codes include a substring?

@jasnell
Copy link
Member Author

jasnell commented Jun 26, 2017

Over-generalization of error codes will make those fairly useless and users will end up parsing the error messages again to find out what actually happened. There's little harm in having specific error codes.

@refack
Copy link
Contributor

refack commented Jun 26, 2017

Over-generalization of error codes will make those fairly useless and users will end up parsing the error messages again to find out what actually happened. There's little harm in having specific error codes.

I suggested two solutions: Either create an OptionError type, or use the a prefix ERR_INVALID_OPT_VALUE_XXX.
My main point is that these are predominantly programing errors and less often runtime errors.

@refack
Copy link
Contributor

refack commented Jul 15, 2017

Superseded by #13976

@refack refack closed this Jul 15, 2017
@jasnell
Copy link
Member Author

jasnell commented Jul 17, 2017

This is not fully superseded. I will refactor. Please do not close.

@jasnell jasnell reopened this Jul 17, 2017
* Move to more efficient module.exports pattern
* Refactor requires
* Eliminate circular dependency on internal/buffer
* Add names to some functions
* Fix circular dependency error in assert.js
@jasnell
Copy link
Member Author

jasnell commented Jul 18, 2017

Updated. I was waiting for #13976 to land so I could drop the internal/errors commit and refactor this. It should be good to go now.

@jasnell jasnell changed the title buffer: refactor buffer exports, use internal/errors buffer: refactor buffer exports Jul 18, 2017
Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

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

Would like to see obfuscated whiles replaced with for...

var i = 0;
while (++i < byteLength && (mul *= 0x100))
val += this[offset + i] * mul;
var val = this[offset];
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're churning let's get some butter: replace with for(...;...;...) to make it more readable. Performance should be on par

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm going to leave these for now. We can hit those in a separate PR

@refack
Copy link
Contributor

refack commented Jul 18, 2017

So I would like to see the obfuscated whiles replaced with for but that might be outside of this PR intended scope...

@refack refack removed the wip Issues and PRs that are still a work in progress. label Jul 18, 2017
@refack
Copy link
Contributor

refack commented Jul 18, 2017

Updated. I was waiting for #13976 to land so I could drop the internal/errors commit and refactor this. It should be good to go now.

@jasnell I'm assuming this is not in progress anymore? Also AFAICT it's semver-patch with the Error changes removed.

@jasnell jasnell removed semver-major PRs that contain breaking changes and should be released in the next major version. errors Issues and PRs related to JavaScript errors originated in Node.js core. labels Jul 24, 2017
@jasnell
Copy link
Member Author

jasnell commented Jul 24, 2017

@jasnell
Copy link
Member Author

jasnell commented Jul 24, 2017

CI is green.

jasnell added a commit that referenced this pull request Jul 24, 2017
* Move to more efficient module.exports pattern
* Refactor requires
* Eliminate circular dependency on internal/buffer
* Add names to some functions
* Fix circular dependency error in assert.js

PR-URL: #13807
Reviewed-By: Refael Ackermann <[email protected]>
@jasnell
Copy link
Member Author

jasnell commented Jul 24, 2017

Landed in 355523f

@jasnell jasnell closed this Jul 24, 2017
@addaleax
Copy link
Member

This doesn’t land cleanly on 8.x; if you can, please follow the guide and raise a backport PR, if you don’t think it’s worth it let me know and we’ll add the dont-land-on label.

@jasnell
Copy link
Member Author

jasnell commented Jul 24, 2017

Unless it causes pain for backporting other things, this is not a priority to backport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
buffer Issues and PRs related to the buffer subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants