-
Notifications
You must be signed in to change notification settings - Fork 115
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
params overloading #4
Comments
I think we should have just one syntax. That last bit is an interesting idea, but how might it play with other things? |
i'd much rather support |
Ohh... okay. But what about not supporting You can even do funny stuff like |
lol why you do that. it's mostly because we support errors and stuff too and i ended up with like 4 if statements then gave up |
Well... I'm gonna try that: rlidwka/sinopia@a5cd498 If it fails horribly, I'll let you know. :P |
What if you also overload the factories to accept Error objects instead of just messages? This way you add the status and pass along the error. something.do(function(err) {
if (err) { return next(create[400](err)); }
...
} |
@chazmo03 we would only do that if you could do the same for |
@dougwilson Looking into the code, index.js:19, it looks like this is already possible, just not documented. Running the following seems to create errors with appropriate codes but with different messages. Am I missing something? createError[400]('Err!').message
createError[400](new Error('Err!')).message
createError[400](new TypeError('Err!')).message |
Um, line 19 is the factory. You are not calling that factory, because you are doing |
I added a deprecation to the one thing everyone agreed upon here: taking the status code as the non-first argument in the factory function. We'll see if there is heavy push back when it gets published. |
Is there any point in doing
create(404, 'message')
when you can usecreate[404]('message')
?Also, you can do
create(404, 'message')
as well ascreate('message', 404)
, which will be pain to support if we decide to change that.I'm now thinking about literally shadowing global Error object with this one:
... and things like treating numbers as status codes might break the idea.
The text was updated successfully, but these errors were encountered: