You could also use the equivalent of a switch statement
warning heavy sudo code


void fsmHeater()
{
bool AreWeDone = false;
int State = 0;
while(AreWeDone == true)
{
switch (State)
{
case 0:
{
Off (oHeater)
Off (oAlarm)
'---
WaitFor(Temperature() < 84)
}break;
case 1:
{
On (oHeater)
Timer = GetmS()
'---
Select Event
Event Temperature() > 85
State = 0;
Event GetmS() - Timer > 6000
State = 2;
EndSelect
}break;
case 2:
{
Off (oHeater)
On (oAlarm)
'---
WaitFor(Input(iResetButton))
State = 0;
}break;
}

}
}

In this instance, given the function in question it's fine.

However given that most FSMs are generally written in a 'do something, optionally set next state, return to caller' manner a goto is unlikely to be a good match in the majority of cases when using/writing a FSM.

Is this a good use of GoTo? This code is supposed to mimic a FSM. Personally, I see nothing wrong with it. Given the function is pretty short. But I wonder if this approach should be avoided: because of a better solution, or just because GoTo is the spawn of evil itself.

FSMs have been traditionally implemented using a switch statement (see above).

The reason lies elsewhere. A FSM is a graph, which can be represented using a matrix. Since all but the most trivial FSMs contain considerable number of states and might be machine generated, using state and action tables is by far the simplest way to implement them.

It has less with style but more with pragmatic approach.

There is another benefit of using state as external variable. One state advancement can act as generator or yield operator. Or put differently, if you call your state machine via some function "advance()", it will move one state, then return, allowing to take action, rather than just having to modify the internals of FSM during development.

In language parsers there is usually nextToken() function, which is a state machine that will return in the middle of processing. Such workflow is typically not possible using gotos.


For fixed FSMs, such as interpreters or VMs, gotos will often be machine friendliest and fastest way to implement them. They are used by JS VMs, for example. They are simply a natural fit, since a FSM is nothing but jmps and gotos translate to those directly.