Skip to content

Exception handling with generators #243

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pfalcon opened this issue Jan 31, 2014 · 3 comments
Closed

Exception handling with generators #243

pfalcon opened this issue Jan 31, 2014 · 3 comments
Labels
rfc Request for Comment

Comments

@pfalcon
Copy link
Contributor

pfalcon commented Jan 31, 2014

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:

  1. 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?)
  2. 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.

@pfalcon
Copy link
Contributor Author

pfalcon commented Jan 31, 2014

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.

@dpgeorge
Copy link
Member

dpgeorge commented Feb 1, 2014

Yes, I need to write code to determine maximum exception stack size in the compiler.

@pfalcon
Copy link
Contributor Author

pfalcon commented Mar 22, 2014

As recent pull request suggests, large part of this was implemented. Closing.

@pfalcon pfalcon closed this as completed Mar 22, 2014
tannewt pushed a commit to tannewt/circuitpython that referenced this issue Jan 5, 2018
/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 fixes micropython#243.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rfc Request for Comment
Projects
None yet
Development

No branches or pull requests

2 participants