Emitting an event on a destroyed scope

[andersekdahl]

Say you have the following code:

function Ctrl($scope) {
  someService.call().then(function() {
    $scope.$emit('some-event');
  });
}

The promise might be resolved after the controller and the scope has been destroyed, which will emit the event into thin air since all listeners on the scope have been removed, and the connection to the parent scope is removed when the scope is destroyed.

The $emit method should perhaps check this.$$destroyed and throw an error in case it is destroyed?

[lgalfaso]

This looks reasonable. PR is welcome

[caitp]

Is it really helpful to throw an error? It doesn't seem especially useful, unless it would help you in debugging.

[lgalfaso]

@caitp I see it as a way to being able to diagnose an issue. My first thought was to just log it, but we do throw an error when calling $digest and a $digest is already in progress (and the fact that there is a stack trace there helps)

[caitp]

If the common time this happens is in response to some asynchronous operation (eg a promise), then the stack trace isn't particularly helpful. So I'm not too sure, but I'm not terribly opinionated about this.

[andersekdahl]

It's definitely for debugging purposes. The reason I opened this issue is because I just helped someone resolve an issue where this was happening. Since events are (like caitp said) often sent after an async operation, you get these subtle timing bugs where it only occurs in some situations.

I don't know if it should throw an error or just use $log. Changing it to throw an error might break existing apps which knows about this fact and don't care. Using $log is perhaps the better way to solve it, but like lgalfaso said, throwing an error could be considered more consistent with the current design.

I'd be happy to contribute with this, if you guys decide weather it should throw an error or if it should use $log. The same should apply to $broadcast I guess. I'd feel better using $log than throwing an error since that error might be considered a breaking change.

[andersekdahl]

Went ahead and created a pull request. Decided to use $log.warn() instead of throwing an error since that error might break existing apps.