We are never going to change this behavior. The event module is "locked"
for a reason.
Your "don't throw" switch is this: er.on("error", function(){})
If you don't like that, you can use a different event name (the best
approach) or use a different event emitter class (not ideal). At this
point on node's life, we're pretty much done discovering our low level
patterns, and at on to optimizing and refining the higher level
abstractions. Changing "error" semantics is incredibly costly, with little
to no benefit.
In fact, since error events ALWAYS throw, the fact that your lib's errors
don't throw violates the principle of least surprise. I recommend usin
another event name.
On Sunday, December 30, 2012, greelgorke wrote:
> whats the problem? if you want to change the halting you have option
>
> 4. assign a handler to process.on 'unhandledException' and override
> standard behaivor:
> http://nodejs.org/api/all.html#all_event_uncaughtexception
> 5. run your app in a domain and handle all your "knownly ignored error
> events" here at once: http://nodejs.org/api/all.html#all_domain
>
> :)
>
> Am Samstag, 29. Dezember 2012 21:02:45 UTC+1 schrieb Jeff Lee:
>>
>> A modest proposal: throwing errors on uncaught 'error' events in
>> EventEmitter should be made optional, rather than mandatory.
>>
>> Looking back at the original thread that proposed the throwing behavior (
>> https://groups.google.com/d/**topic/nodejs/7BU_1BB9zeM/**discussion<https://groups.google.com/d/topic/nodejs/7BU_1BB9zeM/discussion>),
>> I'm surprised at how little debate there was about adding built-in
>> special-case events to a general library class. The throwing behavior seems
>> like an abstraction flaw. Event handles are an "userspace" concept, and the
>> lib/runtime shouldn't be imposing semantics on that. In particular, 'error'
>> is a very generic term, and useful enough that it ought to be reserved for
>> whatever the app intends for it.
>>
>> For example, I might have an app that produces "success" or "error"
>> events. The "error" events may even be anticipated and normal within the
>> concept space of the app. They may be being broadcast simply for logging
>> hooks--if I care to log "error" events, I'll listen for them, but if I
>> don't care, I shouldn't be required to install a listener to prevent the
>> app from halting. You might argue that I should rename the "error" event to
>> "failure" or some other term, but that seems awfully heavy-handed. If
>> variable naming truly is one of the hard problems of computer science, then
>> event naming is similarly difficult, and as such it's a little rude for the
>> API to impose any restrictions, especially for such a semantically
>> ambiguous term.
>>
>> Of course, it's probably not feasible at this point to remove throwing
>> behavior from the API entirely, but it seems fairly easy to change it to a
>> switchable default. One could imagine a lot of different ways of
>> implementing this using module-level configuration:
>>
>> 1. A simple on/off boolean property
>> 2. A method that lets you set the name of the 'error' event, or blank if
>> you don't want the automatic throwing
>> 3. A method that lets you set a common callback for all emitters that
>> aren't handling 'error'.
>>
>> Personally, I prefer some combination of 2 and 3. In any case, if there's
>> interest from the community, I'd be happy to contribute a pull request for
>> this.
>>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to
> [email protected]<javascript:_e({}, 'cvml', '[email protected]');>
> To unsubscribe from this group, send email to
> [email protected] <javascript:_e({}, 'cvml',
> 'nodejs%[email protected]');>
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
