Stop ignoring exceptions in launchAff

[hdgarrood]

launchAff will now throw exceptions rather than swallowing them. Fixes
issue #32

[jdegoes]

The EXCEPTION may be thrown asynchronously, whereas the current signature implies that the returned Eff will throw the exception -- and therefore, that such exceptions can be caught using catchException. The implication is invalid in the general case, only valid for purely synchronous Aff.

Maybe it suffices to amend the comment to, "... and if the computation produces an error, it is thrown, but not necessarily in the current thread of execution.".

[jdegoes]

Originally Aff had something like a LATER effect type which could itself accept a row of effects, but that turned out to have problems with type inference. As a consequence, distinctions between "effects now" and "effects later" can't be captured.

[hdgarrood]

Ah, of course, thanks. Shall I just amend the comment then, or do you want to see if you can think of a better way of writing it?

[jdegoes]

The only other alternative I can see is not adding the EXCEPTION effect type, so as not to give the user the (false) assurance they can catch it. It's fundamentally un-catchable. Maybe that's a sign the user should always have to supply an error handler (and we could provide a global one if it makes sense?).

[hdgarrood]

Ok then - so would we end up with something like launchAff = flip runAff (const (pure unit)) then? What would be the type of the global error handler we might provide?

[hdgarrood]

Or perhaps we could leave the definition like this, but just change the returned type, to, say Eff (errUncatchable :: EXCEPTION | e) Unit?

[jdegoes]

After mulling this over the past couple days, I think the best option right now is to leave it as is, but add the comment. This way you can still 'catch' a synchronous exception (which may in fact happen, since Aff is not necessarily asynchronous), while the comment will warn you away from assuming that future exceptions can be caught synchronously.

Now what we'd really like is for all main functions to expect Aff and not Eff. 😉

[hdgarrood]

Ok, sounds good - I added a comment about asynchronousness and catching exceptions. Although, it has just occurred to me that JavaScript doesn't really have "threads", does it?

[hdgarrood]

Ok, how's this?

[jdegoes]

Thanks!