It's common to use guard clauses but ...

if (condition)

throw something

else

do something else

can be rewritten as

if (condition)

throw something

do something else

A throw breaks execution and hands it over to the error handling/bubbling system of whatever language/platform you are using.

the ELSE is not needed and can be deleted. It's pretty common knowledge that any code that any code that respects the S does not need ELSE clauses (at most IF guards, but never IF/ELSE). This also means that any legacy code with multi-level if guards can be refactored to use a single level and break logic away to other methods (if needed).

So the problem you are 'solving' is to replace if statements and use a state machine as a solution.

A state machine is a nice pattern, sure, but it should solve an application need (eg: can you represent your logic in state transitions? should you do that?) but not be used as a generic refactoring tool.

If you have a number of 'if' guards that gets you think 'OMG, that's way too many', perhaps try good ol' fashion refactoring while keeping SOLID in mind rather than jump to state machine.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store