These are chat archives for pozadi/kefir

25th
Jul 2015
Elia Schelokov
@thaumant
Jul 25 2015 20:11
This message was deleted
Elia Schelokov
@thaumant
Jul 25 2015 20:42

Hello! I was just reading #38 and #103 and got some thoughts. What if the error handling worked like in promises:

  • allowed users to throw errors inside transformers/predicates/etc,
  • caught those errors and emitted them in created observables.

This would add a much more obvious way to introduce an error. And also you could simplify the api having just a single method that converts errors to values (let's call it catch for this example):

  • .catch(err => makeVal(err)) instead of .errorsToValues(),
  • .map(val => { throw makeErr(val) }) instead of .valuesToErrors(),
  • .catch(err => throw modifyErr(err)) instead of .mapErrors(fn),
  • .map(val => { if (pred) throw err ... }) instead of .flatMap(val => { if (pred) return Kefir.constantError(err) ... })

Are there any caveats?

Roman Pominov
@rpominov
Jul 25 2015 21:12
@thaumant Yeah, I was thinking about it. But there is a caveat that it will make debugging harder. Please read this post http://jlongster.com/Stop-Trying-to-Catch-Me it describes what problem promises introduce for debugging. Another my concern is that normally I want errors in a stream to be of certain type. For instance a stream might carry server response or a error that describes what gone wrong on the server, and in the error handler I don't expect some random errors that might be thrown anywhere.
Roman Pominov
@rpominov
Jul 25 2015 21:23
Also you might want to take a look at RxJS and Most, they work basically as you described. I'm not 100% sure which way is better here, but I like how Kefir and Bacon work. I think it good to have choice and use what works better for you.
Elia Schelokov
@thaumant
Jul 25 2015 22:07

I've got accustomed to RxJS and Bacon, also I'm watching over Kefir since the post on habrahabr and about to start using it in production : )

So what do you usually do with the "long tail" of bugs usual in dynamic languages? Personally I prefer failing an operation (i.e. rejected promise) and watching error stacks later over restarting the whole server on uncaughtException because of some Cannot read property 'foo' of null.

Elia Schelokov
@thaumant
Jul 25 2015 22:15
Also the fact that the guy starts a post with regret for the previous one tells a lot : )
(This is not an argument but I cannot but mention it.)
Roman Pominov
@rpominov
Jul 25 2015 22:17
I mostly do client side programming, and maybe on the server side the way Rx/Most work is more reasonable indeed.
But in the browser I usually prefer error to show up in the console, and then run it again with the debugger open and get it paused on the exact spot of the error source.
Then I often want to see the current state of the variables and walk up and down the call stack to see what gone wrong.
Promises usually ruin that workflow completely :smile: