Usando excepciones para romper tus invariantes

Alguna vez se ha dicho que es recomendable mantener la cantidad de estados posibles de un objeto todo lo reducido que sea posible ya que resulta mas comprensible para el programador y menos propenso a errores. Seguir este lineamiento se vuelve mas complejo cuando estamos en presencia de excepciones. Nótese el caso de un método que realiza las llamadas M1..Mn y puede verse interrumpido durante una llamada a un Mi dado que éste arroje una excepción. Si, además, se ha realizado un cambio de estado del objeto antes de llamar a Mi, se está generando un estado intermedio que facilmente puede romper un invariante. En general, podría hacerse la siguiente recomendación:
"durante una llamada a un método, evitar hacer cambios de estado del objeto si posteriormente en el método se realiza una llamada que puede lanzar una excepción y no se piensa manejarla directamente. En caso de decidirse a manejarla puede, en cambio, reasignar al objeto un estado válido (e incluso relanzar la excepción)".
claves: design patterns, Immutable, excepciones
"durante una llamada a un método, evitar hacer cambios de estado del objeto si posteriormente en el método se realiza una llamada que puede lanzar una excepción y no se piensa manejarla directamente. En caso de decidirse a manejarla puede, en cambio, reasignar al objeto un estado válido (e incluso relanzar la excepción)".
claves: design patterns, Immutable, excepciones
