funcool 2023-02-09 | Slack Archive

The new promise impl landed on master and changelog updated acordingly, any feedback is very welcome \o/

@mccraigmccraig I've been thinking about adding the notion of error to streams/channels, and I have 2 main ideas floating around: (A) a Channel error status, (B) or a buffer error status. Errors can happen internally or externally, the internal one is when it happens in the internal reducing function, that is, in the transducer and the external one is when you externally close the channel providing the cause (Exception instance). • In case A, there is a specific problem and that is if you close externally with a cause, and this channel in turn has a transducer that also fails in the final aridity. Which of the two causes is the one that should stay? Does what I say make sense? • in case B, a channel can only be closed with a cause if it has a buffer (channels without a buffer could not have error management since that is only in the buffer). I think that in this case it is more friendly with possible errors in the transducer but less practical when implementing it for external errors. In any case, there are more questions: What happens when you exit on error and you have a buffer containing data, from my point of view you should be able to take the values until it is empty and then return a CF rejected. In the same line that already works now when closing the channel, the closing operation does not clean the buffer, but allows you to take the data until it is empty. Another option that crosses my mind is that the error is one more value in the buffer and when it reaches it, instead of returning the resolved promise, it returns a rejected CF, even though this option is problematic because the next take no longer It will give an exception, that is, the exception would not be permanent if not one more value and would not be a closed state. I have several ideas, but I am not clear yet what properties to achieve. I don't know whether to approach that in the same way as rx/Observable (error is a way of closing) or in another way...

mccraigmccraig18:02:23

i think you always need a channel error state A, because even if you have a buffer error state B too, then that will need to propagate downstream as a channel error state in the case with a channel with a buffer and transducer being closed with an error, but the transducer also erroring in the completion arity - i think there's certainly a programming error in the transducer (whereas closing with an error could be normal/expected operation), so i would tend to prefer propagating that error over the close error in prpr i used a wrapper/marker type on the stream for errors, which has the weakness you point out of only returning an errored promise once - i was constrained by wanting to work with plain streams/chans though and couldn't see another option

mccraigmccraig19:02:00

the properties i've been thinking of are: • close a channel with an error • when closed with an error, take will continue to deliver any values in the buffer and transducer state, but once they are drained then take will thereafter return an errored promise • if the transducer completion arity errors then no more attempts will be made to call it and take will thereafter return an errored promise with that error

niwinz21:02:23

nice, thanks for the feedback

niwinz22:02:42

pushed a branch channel-error-state with the draft implementation

mccraigmccraig03:02:39

excellent! I'm laid low by a nasty little lurgy rn 🤧🥶 but, if my head should clear up enough to think clearly, I'll take this for a spin later

niwinz09:02:06

Relax, first things first. this is not urgent :D

mccraigmccraig09:02:31

lol, I've been getting really bored lying around feeling rubbish... and i can only take so much youtube/netflix... a bit of coding on something I'm enthusiastic about is just the ticket!

niwinz09:02:36

I understand you, I can't stay long doing nothing when I'm sick either. Always looking for an excuse to get out of bed/sofa.

niwinz09:02:40

Returning to the issue of channels, with the current implementation you can close a channel from outside with a cause, but to manage the error in the same way from the transducer you have to use a specific exception handler, I'm still analyzing options and my idea will surely put that effect as default, but I still don't have it 100% clear.

mccraigmccraig14:02:01

does the exception-handler need to be exposed to the chan creator ? obvs exceptions in the transducer must be propagated downstream, but is a recovery mechanism necessary (and on thinking about it - is transducer behaviour even well defined after errors) ?

mccraigmccraig14:02:52

so i think my core question is - after a transducer error, is it sensible to do anything apart from close the stream with the error ?

niwinz23:02:46

channels on promesa an core.async accepts a 4th argument that is an exception handler that defaults to throw unhandled exception (JVM mechanism). From my point of view, the default exception handler on promesa should be that marks channel closed with the cause, but still has the ability to setup a custom handler that does whatever user want to do with the exception

mccraigmccraig10:02:45

that approach seems reasonable

2023-02-09

Channels