Gozala / reducers

Library for higher-order manipulation of collections
MIT License
181 stars 8 forks source link

Do not capture exceptions #26

Closed Raynos closed 11 years ago

Raynos commented 11 years ago

Its far too easy for reducers to "consume/box" errors and for them to just lie there.

This may just be an error with reflex/writer where it doesnt throw unhandled errors.

Something somewhere needs to aggressively throw errors instead of swallow them.

Preferably reducers should throw them and crash everything.

Gozala commented 11 years ago

Writers should handle everything including errors! We should make reflex writer to throw and rant once errors get there, which should never happen!

Gozala commented 11 years ago

Reducers themself can't do that as they don't know if something down the flow is handling an error.

Raynos commented 11 years ago

troll

Gozala commented 11 years ago

I think you're right reducers catch errors to match and then pass those errors to a writer. As a matter of fact even errors from the writers are captured and passed back to writer, which is probably stupid instead these errors should propagate to an reducible implementation itself. Doing this properly may be little tricky, at the moment I guess it will be best to stop streams with errors on exceptions but let those exceptions propagate so that debuggers and other tools could become more useful.

Gozala commented 11 years ago

For the very least reducible function should use throw just for the control flow logic, makes debugging a lot harder.

Gozala commented 11 years ago

After second thought on the problem, it looks like solution may be as simple as make fold report errors when they occur as fold is end consumption so if nothing handler error before that it's very unlikely anything will handle after either. In case we'll need fold that propagates errors it'd be simpler to implement that special fold for those cases.

Gozala commented 11 years ago

Fixed by #31