I don't know why we can't change it. Sure it may break a lot of working code. But as you've outlined, replacing it with more preferable methods is fairly straight forward. It's even easily shimmable for folks who don't want to upgrade. We're talking about breaking nextTick but "can't" get rid of this? Doesn't seem logical.
:Marco On Wednesday, May 30, 2012 9:22:42 AM UTC-7, Isaac Schlueter wrote: > > path.exists (moved to fs.exists) is an abomination for so many > reasons. We can't get rid of it, because it's too widely used, but > it's really pretty awful. It predates the cb(er, data) pattern in > node, and is one of the very few exceptions to it. > > Any time you find yourself using it, you should try to figure out what > you're really trying to find out, and use some other fs call instead. > Usually the best approach is to just try to do what you're going to > do, and handle the error. If you're using a file's existence as a > lock of some sort, it's better to open the file in O_EXCL mode > instead. > > > On Wed, May 30, 2012 at 7:37 AM, Tim Caswell <[email protected]> wrote: > > The most correct value for the error parameter is "undefined", but most > of > > us are lazy and type "null" instead. In most code it expects the err > > parameter to be either falsy or an Error instance, so it doesn't matter > if > > you use false, undefined, null, 0, or even "". > > > > While there are some functions that never emit an error, if there is any > > chance they would emit one in the future, save yourself the trouble and > > reserve the err parameter. Also it makes the function work with > > flow-control tools and wrappers that assume the pattern. > > > > > > On Wed, May 30, 2012 at 4:05 AM, Mariusz Nowak <[email protected]> > wrote: > >> > >> It should be null or undefined only, everything else is a value, and > can > >> mistakenly accepted as an error. > >> > >> There are however asynchronous functions that never resolve with an > error > >> (e.g. path.exists) and as there's no point in always sending null to > their > >> callbacks, they're designed to pass success value as first argument (in > case > >> of path.exists true or false). > >> > >> -- > >> Mariusz Nowak - @medikoo > >> > >> > >> On Wednesday, May 30, 2012 3:24:06 AM UTC+2, Daniel R. wrote: > >>> > >>> Is there consensus on the value to pass to a callback if there isn't > >>> an error and there may or may not be a resulting value. A quick survey > >>> of node.js code along with popular modules seems to indicate that null > >>> is most common but undefined and false also pop up frequently. While > >>> any falsey value works I was curious if one was preferred. > >>> > >>> -- Daniel R. <[email protected]> [http://danielr.neophi.com/] > >> > >> -- > >> Job Board: http://jobs.nodejs.org/ > >> Posting guidelines: > >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > >> You received this message because you are subscribed to the Google > >> Groups "nodejs" group. > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group at > >> http://groups.google.com/group/nodejs?hl=en?hl=en > > > > > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
