laserlemon
commented
6 years ago @tiagofsilva There's no great reason that an organizer uses call! rather than call. The reason I can remember is that we need to be able to jump out of a deeply nested organizer situation, all the way back up to the top-level organizer if any interactor fails. The call! method can achieve this because it raises an error on failure. On the other hand call raises no error and so we have to do some more code acrobatics to halt execution.
Eventually, this should be a moot point because the next version of Interactor should move away from exception raising for flow control, in favor of using throw and catch. Some work had started down that road for v4, but it's non-trivial.
In the meantime, documentation changes are very welcomed. Thank you! :clap:
Hello folks, first of all thank you for this gem and great work! My issue is really a question. You see, I lost a lot of time today trying to test a very basic thing in an organizer. Here's the thing:
I have an Organizer(MyOrganizer) that calls MyInteractor1 then MyInteractor2. I wrap the Organizer in a Database transaction, because I save a lot of records inside this organizer and I don't want to undo each one of them if anything goes south. But in my test I want to verify that the records aren't saved after the second interactor fails. So, I go on and write a test with something like this:
allow(MyInteractor2).to receive(:call).and_raise(StandardError)And for my surprise, #call never gets called! So I had to read the source code to realize that unlike Interactors, Organizers actually use the bang version of the method. Well, why not #call? Secondly, shouldn't it be documented somewhere? Hey, I can help with the second if necessary.
Cheers!