javabeans - Javabeans property description

In trying to set up a consistent way to manage bean properties for my Java project, I sought out the tutorial pages for Java Beans on your site and found the page that specifically addressed what I was looking for: property change support and vetoable property change support (http://download.oracle.com/docs/cd/E17409_01/javase/tutorial/javabeans/properties/constrained.html). But I’m confused as to the suggested process used to support and respond to vetoable property changes.

The suggested implementation of a setXXX method for a “constrained” property is:
1. Save the old value in case the change is vetoed.
2. Notify listeners of the new proposed value, allowing them to veto the change
3. If no listener vetoes the change (no exception is thrown), set the property to the new value.

My first question at this point is: Why save the old value if the property is not changed to the new value unless there are no PropertyVetoExceptions thrown? The 1st item indicates that we are saving the old value because we will change the current property value to the new value and revert it to the old value in the event of an exception. But the 2nd and 3rd items seem to indicate that we should only set the property’s value to the new value if no exceptions are thrown for the proposed new value. But if we only set the property to the new value if no exceptions were thrown for the proposed new value, then there is no need to mark the old value since no reversion is necessary.

Then in the “Handling Vetoes” section that follows, the suggested process for handling a PropertyVetoException is:

1. Catch the PropertyVetoException
2. Revert the property to the old value marked previously
3. Fire a new vetoable property change event indicating the reversion to the old value from the proposed new value

A few more questions arise for me at this point. If no property changes have occurred until after checking for PropertyVetoExceptions (my assumption of points 2 & 3 above), then why is the reversion process necessary? Also, if we truly are changing the property’s value to the proposed new value and reverting it to the marked old value in the event of an exception, then what’s the best way to handle a PropertyVetoException being thrown from the reversion proposal? Understandably, consistent management of the property’s through its setXXX method should prevent a reversion proposal from throwing an exception, but it’s possible the property’s value is invalid to begin with and reverting it to the old value will throw another exception.

It seems to me the simplest process would be:
1. Propose the new property value
2. If no exception is thrown:
a. Set the property to the new value
3. If an exception is thrown:
a. Re-throw the exception

This would obviate the need to track the old value first and would only set the new value for the property if no exception is thrown. However, if the goal is truly change the property value first so that change events are only fired after setting the new value (so that listeners can assume the property has already changed when executing it’s listener process), then it makes sense to mark the value and revert it in the event of an exception.

But if we want to set the property value before firing the event, then I don’t understand the point of firing another vetoable change event. I understand that an exception may not be thrown until after one or more listeners have responded to the new value, but if a PropertyVetoException is thrown again on the reversion proposal event, then changes back to the old value may not take place as needed. Wouldn’t we need a safer way to ensure all VetoableChangeListeners receive the notification that the reversion has taken place, especially those listeners that had responded to the first event before a subsequent listener threw its exception?

It seems better to only set the property value if no exception is thrown and write listeners with the knowledge that although the property’s value hasn’t changed yet, the new value can be retrieved and responded to through the proposed value set in the received event. But again, I can see how a listener and its affected components might only want to respond to the new value if the bean’s property has truly changed to that value so that the proposed value doesn’t have to be passed around in some strange way…

Can you help me understand this whole process or where I’ve misunderstood the processes outlined on the tutorial page?