Open tdd opened 7 years ago
I wouldn't call it incorrect per se. It it inconsistent though, using return
after error in the callback version, and using step()
after error in the Promise version.
How I understand what happens in case of error, in both versions:
task.next()
result.value
)err
on callback, or ends up in catch
clause of the Promise)task.throw
calls the generator, which, in this example, doesn't handle the error thrown at it, and thus the error bubbles up the stack. Given that the error isn't caught anywhere in the generator or the runner, program execution halts, and execution never gets to the following return
/step()
in the runner, so it doesn't really matter whether step()
is there or not. Even the return
is unnecessary.However, if the generator handled the error, then it would make sense to have either return
or step()
. I see this as a choice when designing the runner. You can have either:
return
– a runner which stops executing code of the task after the task encounters and handles an error – strange behaviour, I can't imagine a use case (not saying one does not exist)step()
– a runner which continues execution of the task if the task can handle its errors – which is behaviour I would expectThe decision to abort (handling or not handling the error and returning or not returning) should be up to the task, not up to the runner.
So, I agree that the use case with return
is at least strange, if not incorrect :)
(Or I'm just completely misunderstanding something ¯\_(ツ)_/¯ )
Hi Nicholas,
Location: Chapter 11 > Page 238 > "Promise-Based Asynchronous Task Running" > code at top of page
The following code block almost at the top puzzles me:
You're side-stepping (pun intended) the call to the next
step()
, which doesn't seem right. In fact, your next take on it does take care tostep()
after thetask.throw(err)
.What am I missing here?