-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
Accept string argument for emitting error events #134
Comments
this is so wrong. using strings as errors is a very bad practice. Error objects do have so many advantages. and to put a -100000000 |
@greelgorke, I meant something like this: EventEmitter.prototype.emit = function (type) {
var er;
// other logic
if (type === 'error') {
er = arguments[1];
if (er instanceof Error) {
throw er;
} else if (typeof er === 'string') {
throw new Error(er);
} else {
throw Error('Uncaught, unspecified "error" event.');
}
}
// other logic
}; The error objects can be created based on the string message that is provided when the error event is emitted. |
Note that the error's You can hack the stack trace string, but that seems like a bad idea to enable a small convenience. |
@timoxley, you are right, at least the line where the error event was emitted is in the stack trace on the second place, seems like my suggestion is not so ideal as I thought :) |
@micnic it not even like that in constructs like: function(){
var ee = new EventEmitter()
db.doSomething(query, function(err){
if(err) return ee.emit('error',err);
})
return ee;
} |
Emitting errors based on strings is a bad idea. |
FWIW, you actually don't need to hack anything, the API supports setting a start point for the trace: } else if (typeof er === 'string') {
er = new Error(er);
Error.captureStackTrace(er, this.emit);
throw er;
} |
…n for swipe on chatBox
- Add a `napi_get_cb_info` function to get args length, args, this, and data in a single call - Move the static exception to a class member to enable inlining of the `lastException()` method. - Refactor the `CallbackWrapper` group of helper classes to avoid most (non-inlinable) virtual function calls - Remove use of `v8::TryCatch` (via `NAPI_PREAMBLE`) from several places where it shouldn't be needed. Together, these optimizations reduce the overhead of every JS-to-C++ call through the NAPI layer by approximately 50%.
I do understand that the
events.js
's API is frozen and there is a small chance to change something, but I'd like to be able to emiterror
events using strings, not onlyError
constructor. Now if an error is emitted with a string we getUncaught, unspecified "error" event.
, which is not informative, to receive another message you have specify a new error object with a string message. For me it seems a bit redundant, why not use both methods to specify the emitted errors? In terms of compatibility it should not break any functional, but at least helps to write less and it's quite intuitive.What do you think about this?
The text was updated successfully, but these errors were encountered: