You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See #242 for background of why generators are important.
In vm.c, there's a comment:
// re-raise exception to higher level
// TODO what to do if this is a generator??
nlr_jump(nlr.ret_val);
And indeed, it's rather unclear how to do exception handling with generators.
First of all, we have 2 directions of exception flow:
Exception occurring in generator should be propagated back to caller. Fortunately, throwing exception out of generator terminates it, just the same as returning value from it. (Don't have formal reference handy, but here's: http://stackoverflow.com/questions/11366064/handle-an-exception-thrown-in-a-generator , and it makes perfect sense: normal exceptions are not restartable, so why exceptions in generators would be?)
Exceptions can be injected into generator using generator.throw(). Within generator, they are raised at current yield point.
Then with Py3.3 and yield from, we apparently have not just 2 contexts of "main" and "generator", but stack of generator contexts. Intuitively, these context are higher-order ones than try/except contexts. Within generator, there can be number of enclosing try blocks, and only when exception escapes from outermost block, we have generator context switch, and need to marshal exception.
The text was updated successfully, but these errors were encountered:
Ok, so intuitively what's needed here is to wrap mp_execute_byte_code_2() call in gen_next_send() with nlr_push(), then on caught exception shutdown generator and re-raise exception.
For being able to inject exceptions, we apparently need to make exception stack part of generator state, just like value stack already is, and pass it into mp_execute_byte_code_2(), then just some magic to raise injected exception in context of this exc stack (we just should keep in mind that passing exception as an argument and raising it are 2 different things). This exc stack should account only for lexical try blocks, so should be easy to size.
/docs/design_guide: added links to firmware build learning guides for SAMD21 & ESP8266. Changes were placed in the "Adding native modules" section, since that seemed to me the best place based on target audience.
Updated documentation for `delay()` which fixesmicropython#243.
See #242 for background of why generators are important.
In vm.c, there's a comment:
And indeed, it's rather unclear how to do exception handling with generators.
First of all, we have 2 directions of exception flow:
Then with Py3.3 and
yield from
, we apparently have not just 2 contexts of "main" and "generator", but stack of generator contexts. Intuitively, these context are higher-order ones than try/except contexts. Within generator, there can be number of enclosing try blocks, and only when exception escapes from outermost block, we have generator context switch, and need to marshal exception.The text was updated successfully, but these errors were encountered: