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

Prevent invalid keys from being passed in options. #348

Merged
merged 3 commits into from
Dec 22, 2015

Conversation

eventualbuddha
Copy link
Contributor

These are all the keys needed to make the test pass, but I may have missed something.

@eventualbuddha
Copy link
Contributor Author

@Rich-Harris ping.

@Victorystick
Copy link
Contributor

@eventualbuddha Good idea. I see you're throwing an exception instead of returning a rejected Promise.

Since you're doing argument validation, throwing makes more sense to me. The reason I point this out is that the two other argument validation conditions return a rejected Promise instead. I think those should probably throw as well.

@eventualbuddha
Copy link
Contributor Author

@Victorystick ah, good point. Those should be consistent, I agree. It might make more sense for the function to always return a promise, though. That way callers simply need to have a .catch( call chained as the sole way to handle errors. Making validateKeys return a promise would be a little strange, though, so perhaps it's best to wrap it somehow in the call to rollup?

@Victorystick
Copy link
Contributor

Isn't there a semantic difference between a rejected Promise and a thrown Error? I agree that it's better to have a single way to catch errors, but these are two completely different kinds of errors, no?

@eventualbuddha
Copy link
Contributor Author

Imagine a caller of the rollup function wants to handle errors. With the
way it's done now there are two kinds of error: immediately thrown errors
and rejected-promise errors. That means you need something like this:

try {
rollup()
.then()
.catch(/* rejected promise handler */);
} catch (err) {
/* immediately thrown handler */
}

Whereas if we always return a promise you can drop the surrounding
try/catch.
On Tue, Dec 8, 2015 at 8:14 AM Oskar Segersvärd notifications@github.com
wrote:

Isn't there a semantic difference between a rejected Promise and a thrown
Error? I agree that it's better to have a single way to catch errors, but
these are two completely different kinds of errors, no?


Reply to this email directly or view it on GitHub
#348 (comment).

@TrySound
Copy link
Member

TrySound commented Dec 8, 2015

@eventualbuddha @Victorystick If we use promises in rollup then we should always reject and error with it. As an alternative you can wrap all in Promise and throw an error there

function rollup() {
  return Promise.resolve().then(function () {
    throw Error('Some error');
  });
}

This will be the same as returning Promise.reject();

@arv
Copy link

arv commented Dec 8, 2015

FWIW, this is the same motivation why ES'15 Promise functions do not throw but return rejected promises.

Promise.all(42); // rejected Promise

(V8 gets this wrong #4603)

@TrySound
Copy link
Member

TrySound commented Dec 8, 2015

@arv Doesn't matter in this case

@eventualbuddha
Copy link
Contributor Author

I'll redo it with the semantics discussed.

@eventualbuddha
Copy link
Contributor Author

Done. Added a test for it as well.

@Rich-Harris
Copy link
Contributor

I took the liberty of replacing the for...of loop with a while – with our current build setup, for...of isn't actually transpiled. We could add that setting to the .babelrc, but it doesn't transpile well, so I tend to include it in the 'ES6 features to avoid' category.

Rich-Harris added a commit that referenced this pull request Dec 22, 2015
Prevent invalid keys from being passed in options.
@Rich-Harris Rich-Harris merged commit ea5970f into master Dec 22, 2015
@Rich-Harris Rich-Harris deleted the validate-options branch December 22, 2015 15:43
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

5 participants