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
In auto-update it looks like you insulate the worker loop by catching exceptions and converting them to impure exceptions:
...
a <- catchSome $maybe (updateAction us) id (updateActionModify <*> maybea)
...--| Turn a runtime exception into an impure exception, so that all 'IO'-- actions will complete successfully. This simply defers the exception until-- the value is forced.catchSome::IOa->IOa
catchSome act =Control.Exception.catch act $\e ->return$ throw (e ::SomeException)
It makes sense to me why you'd need to protect that loop. However, the user gets back an action IO a to demand the current value. I think it's reasonable for them to expect that when they evaluate that IO a, any exception would get thrown and if it didnt, the auto-update succeeded. However, if they don't strictly evaluate the a, then it can work its way into less defensively coded areas and blow up on evaluation. I had some code that was running something like tryAny demand and the exception escaped.
I'd like to suggest replacing catchSome with the equivalent of tryAny from safe-exceptions. The worker loop would still be safe from async exceptions. Then in the demand function you give to the user, pass that through either throw pure so they still get an IO a but the exception gets forced in a predictable place. What do you think?
The text was updated successfully, but these errors were encountered:
In
auto-update
it looks like you insulate the worker loop by catching exceptions and converting them to impure exceptions:It makes sense to me why you'd need to protect that loop. However, the user gets back an action
IO a
to demand the current value. I think it's reasonable for them to expect that when they evaluate thatIO a
, any exception would get thrown and if it didnt, the auto-update succeeded. However, if they don't strictly evaluate thea
, then it can work its way into less defensively coded areas and blow up on evaluation. I had some code that was running something liketryAny demand
and the exception escaped.I'd like to suggest replacing
catchSome
with the equivalent oftryAny
fromsafe-exceptions
. The worker loop would still be safe from async exceptions. Then in the demand function you give to the user, pass that througheither throw pure
so they still get anIO a
but the exception gets forced in a predictable place. What do you think?The text was updated successfully, but these errors were encountered: