error handling #462

Closed
yawnt opened this Issue Sep 15, 2013 · 12 comments

Projects

None yet

4 participants

@yawnt
Contributor
yawnt commented Sep 15, 2013

No description provided.

@yawnt
Contributor
yawnt commented Sep 17, 2013

fixed in #470

@yawnt yawnt closed this Sep 17, 2013
@jcrugzz jcrugzz reopened this Sep 19, 2013
@jcrugzz
Member
jcrugzz commented Sep 19, 2013

This should be documented somewhere. related to #463

@jcrugzz
Member
jcrugzz commented Sep 21, 2013

The root of the problem is that listening on a wildcard error listener (ee.on('*:error', function (err) {}) does not get picked up with this check so we will always throw an error in this use case. We should hae

@yawnt you think we could simplify the error listener in some manner (maybe to a simple ee.on('error', function (err) {})? I feel like most use cases will only need this.

@jcrugzz
Member
jcrugzz commented Sep 23, 2013

As @srossross confirmed, we cannot use a single wildcard to cover multiple delimited sections. So if we are to continue to namespace the error handling in some way, we should choose something simpler.

So we should think about what distinctions are important when handling errors. The web:error and ws:error idea seems reasonable as we may want to handle those cases differently for cleaning up connections. @yawnt what are your thoughts?

@yawnt
Contributor
yawnt commented Sep 23, 2013

yeah i've been trying to find a better way without losing the 'incoming/outgoing' differentiation.. since i have no idea yet i'll refactor like you suggested

@3rd-Eden
Member

Why not drop whole silly namespacing completely and just "tag" the error instances with a type so people and we can filter based on that? For example:

var err = new Error('WebSucket failure');
err.type = 'ws';
@yawnt
Contributor
yawnt commented Sep 27, 2013

not bad at all actually.. how close is EE3 to completion @3rd-Eden ? if i have to refactor i'd like to use that

@3rd-Eden
Member

@yawnt EE3 works as intended, differences between normal EE and EE3 are explained in the README: https://github.com/3rd-Eden/EventEmitter3 ( also, it doesn't have namespaces ;-), never found them useful enough to implement )

@jcrugzz
Member
jcrugzz commented Sep 27, 2013

@yawnt @3rd-Eden this sounds like a win. \o\

@yawnt
Contributor
yawnt commented Nov 7, 2013

server.on('error' was implemented.. namespaces were also dropped

@yawnt yawnt closed this Nov 7, 2013
@srossross
Contributor

I just upgraded to the latests http-proxy in npm (1.0.2), I am using express JS and I get this error:

TypeError: Object #<Socket> has no method \'status\'

from my server.on('error', function(err, req, res) { error function because this is a websocket error, how do I distinguish between the two types of errors?

@jcrugzz
Member
jcrugzz commented Feb 4, 2014

@srossross yea i have been thinking how these should be separated. wsError is the best I've come up with for segmenting the two but still subideal. For now just do a check for res.statusCode or something of the sort. Messy I know but I'd love your thoughts on what you think works :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment