Right now, if a behavior function raises an exception, there are cases where a TypeMachine will end up in an inconsistent state.
In particular, if a data factory raises an exception, it will do this after the machine has already transitioned to the state that expects the data to be populated. As such, this exception will leave the TypeMachine in a persistently broken state, and worse, one which will be receiving the wrong type of object to its behavior functions (most likely a None, I think, although possibly a previous data-state's object sometimes?)
A few changes need to be made:
[ ] if any user-defined behavior raises any BaseException, the machine should be restored to some consistent state; the Transitioner must transition to a defined error state, so that (by default) all input methods on it raise exceptions.
[ ] most critically, if any data factory raises any BaseException, it must transition to this sort of error state. (non-data states might be in trouble because they're in the "wrong" state without their transition code having been fully executed, but that's arguably recoverable, or at least not in violation of any type signatures; a data factory blowing up just breaks all expectations of later code)
[ ] That state should be an explicit state that the user has some ability to define, so that they can recover out of it. (Error states must not, for obvious reasons, be states with state-specific data)
Right now, if a behavior function raises an exception, there are cases where a
TypeMachinewill end up in an inconsistent state.In particular, if a data factory raises an exception, it will do this after the machine has already transitioned to the state that expects the data to be populated. As such, this exception will leave the
TypeMachinein a persistently broken state, and worse, one which will be receiving the wrong type of object to its behavior functions (most likely aNone, I think, although possibly a previous data-state's object sometimes?)A few changes need to be made:
BaseException, the machine should be restored to some consistent state; theTransitionermust transition to a defined error state, so that (by default) all input methods on it raise exceptions.BaseException, it must transition to this sort of error state. (non-data states might be in trouble because they're in the "wrong" state without their transition code having been fully executed, but that's arguably recoverable, or at least not in violation of any type signatures; a data factory blowing up just breaks all expectations of later code)