I have an event that is raised when my job objects change state (e.g. initializing, running, complete, etc). The event is to be invoked from my set method in the State
property, but before I make it that far, I'm trying to determine what makes more sense from a consumer standpoint. The event declaration is:
public event EventHandler<JobState> StateChanged;
This means the subscriber signature is:
void Job_StateChanged(object sender, JobState e) { ... }
As a result, I can't help but wonder if e
should be the current state, or, since State
holds the current state, if it should be the previous state instead.
Alternative Solution
If I create a StateChanging
event instead of StateChanged
, the state of the job in e
seems less ambiguous, at least to me. The naming of StateChanging
implies that the State
property's value has not yet changed, but is about to change to the value specified in e
.
However, my concern with this approach is that the naming also implies that the consumer can prevent the state change from completing, which I don't want to permit.
Should I send the current or previous state with my state changed event; or, should I go with a StateChanging
event instead?