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

fixes #1 #2

Closed
wants to merge 4 commits into from
Closed

fixes #1 #2

wants to merge 4 commits into from

Conversation

weichensw
Copy link

No description provided.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 1e07c51 on xbtsw:master into 9586469 on omsmith:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 1e07c51 on xbtsw:master into 9586469 on omsmith:master.

@omsmith
Copy link
Owner

omsmith commented May 4, 2015

Is the errHandler because you'd provide a new one for use on the "upgrade" event?

I would also hesitate calling this an error handler, as it is simply a "default" or unmatched handler, yes?

Maybe we expose this as .default(fn);?

@omsmith
Copy link
Owner

omsmith commented May 4, 2015

It should be invalid to not have a default handler, so the check for if(this._errHandler) (or whatever new name) in the dispatcher is unnecessary

@weichensw
Copy link
Author

the dispatch will call handler(arguments) since websocket will have 3 arguments (instead of res and req), this errHandler is called when there's no route matching, instead of res.end() directly, since in websocket, there's no res anymore.

So in a sense, it's a error (no route matched). The original behavior here is 404 and res.end(), which have the assumption of a http request.

@weichensw
Copy link
Author

I agree the if(this._errHandler) is redundant now. Initially I didn't have a default for the errHandler so I have a if check when calling it. (i.e. I didn't errHandler || function(){...}) and later on I changed it into the current way. I will remove it.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling afbe013 on xbtsw:master into 9586469 on omsmith:master.

@omsmith
Copy link
Owner

omsmith commented May 5, 2015

Not on my phone anymore so perhaps I can write a more detailed answer.

Don't think errHandler is a good name here. An error handler should just be another way of specifying .on('error', listenerFn) and stop the error events from being raised.

This would be better exposed as a default handler. As that's the only "error" it handles.

For example:

PathRouter.prototype.default = function setDefaultHandler () {
  this._router.default.apply(this._router, arguments);
  return this;
}
function defaultHandler (req, res) { /* ... */ }

function Router () {
  // ...

 this._default = defaultHandler;
}

Router.prototype.default = function setDefaultHandler (fn) {
  if ('function' !== typeof fn) {
    throw new Error('"fn" must be a function');
  }

  this._default = fn;
}

Router.prototype.dispatch = function dispatch (req) {
  // ...

  this._default.apply(this, arguments);
}

If it doesn't matter to you - I could actually write that out and commit it with tests in place.

@omsmith
Copy link
Owner

omsmith commented May 5, 2015

I've got those changes in #3 which I'll merge once the tests pass.

I'll do the any-arity handler change after

@omsmith omsmith closed this May 5, 2015
@weichensw
Copy link
Author

I see your point now. Yes I agree in this perspective it can be called default too.

I don't really mind the name, so long as the any-arity handler is there :)

Thanks for the help!

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