Closed kika closed 7 years ago
The first place to look is here. Make sure any place which can cause an exception will call the onErr
callback.
@jdegoes Does this mean that functions in Aff indeed do not catch exceptions and we need to catch ourselves and call error callbacks?
In Aff.js _attempt
does use try...catch...
, _runAff
doesn't, _liftEff
does again. I can't understand the system and difference.
@kika If you create your own Aff
, you need to make sure that you always use the error callback in the event of an error. I am not sure why _attempt
uses try / catch, probably we can delete that. The point is that if you create your own native Aff
s which are functioning correctly, then attempt
will always "catch" the error (through the error callback). If that does not happen, then it's a bug in Aff
and will be fixed right away (in this case, I am not sure, but the Javascript code does not look safe to me).
@jdegoes ok, thanks, got it. So the takeaway is this:
Aff
s and call error callbackstry... catch...
in _attempt
actually does anything only if aff()
function is synchronous. I've read up on async exception handling in js and it seems that you can't catch the exception this way, so indeed this try/catch pair is not necessary.
CC @ThimoteusAff
now only uses try/catch
in liftEff
and makeAff
. It's expected that anything else uses the error channels.
It appears that
attempt
is supposed to handle exceptions in the Aff function it runs, but it doesn't despite having atry ... catch...
block in its FFI implementation. Repro case:reddit.com
toreddit.com:8088
at https://github.com/Thimoteus/purescript-simple-request/blob/master/test/Main.purs#L34pulp test
The program bails out with
EPROTO
exception (because there's nothing ready for SSL handshake at port 8088).Expected result:
Left Error
fromattempt
with the corresponding exception.