Is there are way we can completely avoid illegal states rather then throwing an IllegalStateException when a method is called when it should not be?
For example:
public interface Process {
void start();
void stop();
}
Illegal state would be created if stop() is called before start().
Illegal states are that, state. Compilers of most programming languages do not concern themselves with state, only with the types of states.
So, to prevent those errors (or rather, raise them at compile time rather than at run time), you need to encode your state in a way the compiler can understand. For most general purpose programming languages this is going to be a real chore to do and a major pain to use, if not even impossible.
There are, however, languages and compilers that model the possible values of a variable/object in the type system and can provide a lot of compile time safety in that regard (official term: dependent types). The Wikipedia Page lists a few example languages.
You can avoid illegal states by starting in a legal state and disallowing transitions into illegal states.
The problem is enforcing that in a system complex enough to get useful work done.
The code you posted is trivial enough that it can be fixed simply by adding another type to represent your missing state.
You seem to be using some Java like language so here's one way to fix your code:
public class Stopped {
Started start() { ... }
}
public class Started {
Stopped stop() { ... }
}
Here the compiler is enforcing that these methods be called in order. I don't even have to look at the using code.
But add a simple feature and watch it all fall apart. Lets say we're simulating an internal combustion engine. The kind in your car. That's seems like it should be fine. Those start and stop all the time.
Lets add a throttle. You know, a gas peddle. When started it makes the engine rev. When stopped it floods the carburetor.
That actually works fine. Add a little polymorphism. Started and stopped now both implement a throttle interface. Spiffy.
Then someone up and decides that throttles are not binary. They go from 0% to 100% open. So they decide to pass numbers from 0 to 100 to the throttle method. Sounds fine. But they used an int.
Can you see the problem yet? Sure 0 works. 100 works. Anything in between works. So we're fine right?
Well no we're not. Before, we didn't have to look at the complex using code. We could prove our code stays in valid states just by reviewing two classes. Now we have to review everything that touches our code.
The problem, of course, is that an int allows more than 0-100. We can pass negative numbers, maybe hoping to go in reverse, and we can ask the engine to give 110%. While that looks great on motivational posters it can easily put us into an invalid, undefined, state.
Now you can, and should, try to fix this with validation but this is what drives us to give up on proving that code works and instead lean on testing. Our code is going out into a wild and wooly world full of code that we may never see. When that code touches our code it could pass whatever.
So what you do, to prevent invalid states, is control transitions, validate input, and test the hell out of it.
A single 4 byte int has billions of states. You going to test all that? Of course not. What you do is something called state space partitioning. Which is a fancy way to say test the limits of your boundaries. In this case you'll want throttle tests for -1, 0, 100, and 101. That tests each side of your upper and lower boundaries.
That should give you something called code coverage. Each branch of code gets exercised by tests. Even the ones that are supposed to throw an error in your face.
This still won't that prove that you can never enter an invalid state. But it's the closest we can come in a language like this.
If you need something more formal and provable, look into Scala.
Stopping in a stopped state would just be a nop operations, so do nothing. No IllegalStateException need be thrown, just return immediately from the method if the system is in a state where the stop operation would be meaningless.
Similar with the start operation. If the system is already started, it would be a nop operation.
Of course for a more complex system, with more states and operations, things can get tricky. What to do when you for example restart is called, and the system isn't started? Do you then relegate to start instead, of throw an IllegalStateException? That's a design decision, and would depend at least in part on the complexity of the states involved. If restarting is more than just stopping and starting, you can't just do a start if the system isn't stopped for example.
The right answer is complicated, but it seems to be no, depending on how you look at things. You may be talking about development time or execution time. I will talk only about execution time.
You are implementing a state machine. The state machine, at any point of execution, has to have a current state.
Transitions are triggered by the occurrence of events originating from outside your state machine. A state of your state machine will be "illegal" if the outside of your state machine does not make events occur in the order the specifications say. It may happen, in any case, be it because you program launches while the outside world is not in its initial state, because the ouside world is buggy, or because events are maliciously unordered.
The only choice for you have, for your system to be robust, is to map every state/event pair to a pair consisting of a triggered behaviour and a new state.
The triggered behaviour may be an exception thrown.
[*caveat: I assume process -> concurrency]
To me, there's no generic way to avoid illegal state because there is no general definition of 'illegal state.' Illegal states don't figure in Turing machines or the lambda calculus. If an illegal state exists, it exists via design.
Illegal states are the result of a particular implementation of a particular business logic or application domain. For example, the business logic of Linux processes doesn't worry whether a process is started or exists when kill sends a signal to a process. reference:
$> kill -0 2733
bash: kill: (2733) - No such process
$> kill 2733
bash: kill: (2733) - No such process
To me, signals look quite a bit like message passing if I squint hard enough. The behavior of Linux/Unix signals may or may not be what you want. But it is worth considering that the way in which Linux/Unix handle stopping processes reflects the design thinking of many very competent engineers over several decades.
Looking at the design of Linux/Unix processes the interface seems to leave some design questions.
start() relate to process creation? stop() relate to process destruction?The answers can form the basis for determining what is and isn't an illegal state.
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
Illegal state would be created if stop() is called before start()-- No,stop()just does nothing, because there is nothing to do. – Robert Harvey♦ May 12 at 17:22interface ProcessBuilder {Process start();} interface Process {void stop();}but you can still stop a stopped process. – immibis May 13 at 1:45