-
Notifications
You must be signed in to change notification settings - Fork 271
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
parser-error vs user-error #42
Comments
I didn't even realise that it would capture user thrown errors. Not sure if can be seen as a bug or as a feature, as I can that this can be useful but also really annoying. I'm just going to label this as a Note: We could use https://github.com/NobleJS/setImmediate for this. |
Yeah, emitting |
Good to know that it's working, but not sure if that would be the optimal solution for this. I think it makes more sense to update the parsers https://github.com/3rd-Eden/primus/blob/master/parsers/json.js#L11 so they call the |
Ohhhhh I see now... Good call, I'll go ahead and fix them that way. I don't really see the need to make the exports.decoder = function decoder(data, fn) {
try { data = JSON.parse(data); }
catch (e) { return fn(e); }
fn(undefined, data);
} Though, I guess you could also drop exports.decoder = function decoder(data, fn) {
var err = undefined;
try { data = JSON.parse(data); }
catch (e) { err = e; }
fn(err || undefined, data);
}; |
Yes, your first example was exactly what I was thinking. The second example would also work and can be written cleaner as well: exports.decoder = function decoder(data, fn) {
var err; // err is always undef when not nothing is assigned to it.
try { data = JSON.parse(data); }
catch (e) { err = e; }
fn(err, data);
}; |
Ah with this fix, it shows an actual failed test when using binary-pack. When checking for Want to just ignore anything that's not a string? Seems silly to cast the buffer right back to a string... Meh? |
@gjohnson whoops, yes I think a simple |
Closing this. It was fixed in #43 |
I noticed that not just parser errors get handled nicely and emitted (if anyone is listening) but actually any exception that may occur within a "data" event handler. Whether this is an issue or not boils down to opinion, but might be worth to note it somewhere in the docs that error handling is not just limited to server/socket/parser errors.
The text was updated successfully, but these errors were encountered: