catchException should not eliminate the effect

[natefaubion]

It is very misleading, and often a lie in the presence of asynchronicity. There are no clear semantics as to what it means to actually eliminate the effect (vs. purescript-run). I think it's better to just introduce the effect on both catchException and throwException. So you can't say "all exceptions are caught", you can only say "we are using the exception system provided by the host".

[paf31]

I don't think the problem is with catchException though. I agree there is something difficult with catchException in the presence of asynchronous exceptions, but I think there can be a clear semantics (at least relative to some semantics for JavaScript functions which takes exceptions into account). We can say that Eff (exception :: EXCEPTION | eff) a means a function which can run in a context supporting synchronous exceptions. This means something is wrong somewhere when we start using asynchronous exceptions. I think the problem is when we give a type like

(a -> Eff (exception :: EXCEPTION | eff) Unit) -> Eff (exception :: EXCEPTION | eff) Unit

to a function which can throw exceptions asynchronously. This says we get back an action which can be run in a context supporting synchronous exceptions, which is untrue, and catchException cannot be expected to catch an asynchronous thrown here.

[natefaubion]

This is right, and basically what I tried to do with the new Aff. But then you can introduce exceptions "purely" and runPure them and kill your program with impure exceptions 😆. So you can say, "I am giving it these semantics", but people take it to mean whatever they want, and it's most often just misleading.

[garyb]

Resolve in the 0.12 branch, since we don't have effect rows there.