Java – Should we validate a state transition before attempting it in the State Pattern

cdesigndesign-patternsjavaobject-oriented

When applying the State Pattern illegal transitions should result in an exception being thrown (or at least that's what I understood from the pattern)

I know exceptions are for "unexpected behavior" where an action isn't supposed to happen. Errors would be more appropriate if the required action is common (ex: user enters a wrong password)

Now picture this, I have an admin panel where a list of orders are shown and each order has 3 buttons (Refund, Cancel, Reorder) where each one of them changes the state of the order if the operation is allowed.

The 3 buttons are enabled by default (I'm simplifying my case here as my real system is much more complex than that). Now a user can for example push the cancel button for an order with state (Cancelled) which is an invalid state transition.

Since I expected that this illegal transition action to occur would a validation before attempting to Cancel the line be more appropriate?
If I validate before transition do I still need exceptions in the model?
Is there a better approach to the whole problem (ignoring disabling the buttons and client side validation)

Best Answer

Client-side measures can never solve such a problem. Even if you disable smth and/or place validation, it is still possible to send invalid requests.

In this case I would disable the Cancel button in the UI. When the server receives a request to change state, I would validate it at server-side, ignore the request if the state is invalid and send an error status back to client. depending on the situation, I would also show an error message like The order has already been canceled.

Related Solutions

Java Design Patterns – State Pattern vs Inheritance

No, the state pattern does not fail. Just make the additional "cancel" attributes part of the "Cancelled" state, and the additional "refunded" attributes part of the "Refunded" state ( you just forgot the latter state in your diagram, I guess?)

Since any "state" entity is an aggregate of the SalesOrder, any attributes of "state" can be seen just an "addition of details" to the SalesOrder.

Which kind of inheritance mapping you choose for your OrderState hierarchy actually does not matter for your problem, any of the typical three will work .

The state pattern also allows you to keep attributes of a former state even when the state changes afterwards. For example, you might need to keep the "shipping address" even when the state changes from "Shipped" to "Invoiced". This can be solved by allowing multiple states at once, just make the relationship between SalesOrder and OrderState "1:n" instead of "1:1". So you don't "change the state from shipped to invoiced" but add the additional state "invoiced" to an entity "StateOrder", without removing the state "invoiced" beforehand. Of course, using this model, when looking for all orders to be shipped, you must check not only for orders which are "granted", but for "orders which are granted but not already shipped". But that's only a detail in the processing which should not be too hard to handle.

Having multiple states is IMHO the "better" model, since it reflects the real world situation more adequate. For example, something you have shipped and invoiced is "shipped and invoiced", not "invoiced instead of shipped".

Java – Ignore exception when closing a resource such as a file

The reason, which as I recall Bloch explains, is that the interesting Exception is the original one thrown from within the try block. Any Exception thrown within the finally block will hide the original Exception.

Imagine that the ur-Exception is because the File is on a network and the network is down. That's the more informative Exception that you want to throw. But that problem also affects the close() , and you don't want the 2nd exception to "get in the way".

Note this explanation was in V1 of his book...

Added The following code proves the point:

try {
  throw new Exception("in try, here is the ur-Exception");
}
finally {
  throw new Exception("in finally");
}

The second, "in finally" Exception, is the one you will see, hiding the original Exception.

Related Topic