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
Real world long running programs may not want to fail on unexpected exceptions. As it stands if an exception is raised by a user defined signal or event it usually renders the whole reactive system inoperant (e.g. mutables will still be associated to a step that failed hence preventing further new schedules). Without looking it into deeply I see two approaches:
Catch exceptions at the level of the update function call and trap them to a user defined
trap. E.g. like fut does [1][2].
Let it flow until execute and cleanup the step (go through the step's priority queue and set the update step stamp of the nodes to Step.nil.).
In general 2. may break much more invariants when an exception occurs than 1. For example it may break the semantics of nodes unrelated to the one that raised (but just happen to be a dependent of the same node). With 1. only the nodes that raises and its dependents break, so I think I'd prefer to go along the lines of 1.
As a side effect we should also try to see if there's something we can do to report better information about the source of the raise, currently it always report the start in react.ml which is not that helpful (note, this doesn't seem to be the case in fut, why?)
The text was updated successfully, but these errors were encountered:
Real world long running programs may not want to fail on unexpected exceptions. As it stands if an exception is raised by a user defined signal or event it usually renders the whole reactive system inoperant (e.g. mutables will still be associated to a step that failed hence preventing further new schedules). Without looking it into deeply I see two approaches:
trap. E.g. like
fut
does [1][2].execute
and cleanup the step (go through the step's priority queue and set the update step stamp of the nodes toStep.nil
.).In general 2. may break much more invariants when an exception occurs than 1. For example it may break the semantics of nodes unrelated to the one that raised (but just happen to be a dependent of the same node). With 1. only the nodes that raises and its dependents break, so I think I'd prefer to go along the lines of 1.
As a side effect we should also try to see if there's something we can do to report better information about the source of the raise, currently it always report the start in
react.ml
which is not that helpful (note, this doesn't seem to be the case infut
, why?)The text was updated successfully, but these errors were encountered: