In this case the tracker was removed on the second line but it was reinitialized on the third line, which is not obvious based on the snippet. Reinitializing the tracker also means that various autotracking features may be reactivated and unexpected events tracked.
I would like to prevent this behaviour and just return NULL from the getNamespace() and other functions from the TrackerController but I realized that this would be a breaking change. We would need to change the signature of the TrackerController functions.
So in order to prevent making the breaking change, this PR:
Logs an error when a tracker that was previously removed is accessed. This should make it easier for users to debug the weird behaviour.
Renames some of the internal functions to make clear that they are not just getters but can also change the objects (e.g., getTracker() -> getOrMakeTracker()).
Issue #548
The problem that we are dealing with here is that users got confusing behaviour after having code that did something similar to this:
In this case the tracker was removed on the second line but it was reinitialized on the third line, which is not obvious based on the snippet. Reinitializing the tracker also means that various autotracking features may be reactivated and unexpected events tracked.
I would like to prevent this behaviour and just return NULL from the
getNamespace()
and other functions from theTrackerController
but I realized that this would be a breaking change. We would need to change the signature of theTrackerController
functions.So in order to prevent making the breaking change, this PR:
getTracker()
->getOrMakeTracker()
).