You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
glyph
changed the title
error handling for TypeMachine
exception handling for TypeMachineAug 21, 2024
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 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; theTransitioner
must 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)The text was updated successfully, but these errors were encountered: