State Pattern Add-on thought

Just a note from my gumball's little thought.., for the next text, I'll use gumball machine as a case study (you might wanna read headfirst design-pattern first)

assume that you already met with state pattern, or better, you've implement it!
context class:
is a class of an object that may have many different state.
state class :
is a class contains spesific behaviour for each state an object can have.

• if the transition is dynamic (depend on some condition/value), then it is more apropriate if the transition placed on the state classes, this way we have decide that we'll close the context class for modification,
  
• if the transition is static (for every spesific event, always change to some other state), then it is more apropriate to place the transition logic on context, this way we have decide that we'll close the state class for modification
  
• between state classes should dependent or coupled ?
  
  • if we decide to have transition controlled by state class(dynamic transition) then we cant avoid the coupling between state classes,
    
  • if we decide to have transition controlled in context, we can try to make those state classes more independent
    
• the way I see it, when we choose which class should be close for modification, the context or the state, is a matter of state capability(intelligence), if we decide the transition logic to be placed in state classes then we have made our state class more "intelligent", and so vice versa. Personally I'd chose the former (for now), yes we'd sacrifice the low-coupling between state classes, but it'll make the context a lot more solid, and as the definition of state pattern is to group behaviour into a spesific class based on it's internal state, my point of view is that state transition is also part of context's behaviour --CMIIW--
  
• if you do have some conditional check, make sure that the checks on each state are specific, remove all redundant checks, because every check should be done on responsible state
  for example:
  
  • there's no need to check whether gumball still available on StateHasCoin, because we are certain that the gumball is surely available in StateHasCoin, if it is not available, then our machine would have gone straight to SoldOut state, without going through NoCoin and HasCoin state (imposible paths)
    
• it is best to have exception mechanism, because for every event there can be many current state method invocation(many line), which on every line the currentstate may have change to a different state class,
  so the idea is that exception will stop execution of state method on relevant state, it help to track the system state easily when the error happens.
  for example:

<?php
//if the current state is no_coin
public function pullLeverEventHandler() {
   /*
   * we still on no_coin,
   * below line tells that we cant pull lever
   * because we havent inserted any coin
   */
   this->getState()->pullLever();
   /*
   * we still on no_coin,
   * below line tells that we cant dispense
   * because it is invalid event for current state
   */
   this->getState()->dispense();
}
?>

we have two error up there, so the question is...

• which of em should be displayed? one or all of em ?
  
• the order of the message ? ( invalid event, you haven't insert coin) or (you havent insert coin, invalid event) etc..

solutions: use exceptions, it will halt on first state method invocation, then it will make more sense, --CMIIW--

please throw me an argument :p ...