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
Closure iterator ignores "return" if exception is raised and caught in finally #20362
Comments
I fail to see the bug here. When it reaches try:
yield 10 # just to force transformation
raise newException(IOError, "")
except:
discard it first yields 10. On the next iteration |
Or in other words try:
return 5
finally:
try:
yield 10 is undefined behavior as the |
I don't think yield is supposed to "abort a return" or "do continue afterwards" iterator a: int {.closure.} =
try:
yield 5
return 5
finally:
yield 10 # should "abort return"
echo "hey iterator" # should run, but doesn't since return isn't aborted But that's not the case imo, we should have exactly the same flow between an iterator with no yield, and one with yields everywhere. |
Interesting. I thought that one would abort the return too. Well and it does, doesn't it: iterator a2: int {.closure.} =
try:
yield 5
return 5
finally:
echo "A"
yield 10 # should "abort return"
echo "B"
echo "hey iterator" # should run, but doesn't since return isn't aborted
for x in a2(): echo x produces:
|
The semantics are "after a return run the finally section including its yield instructions". That seems pretty consistent and reasonable to me. |
Indeed. However, if an exception is raised & swallowed in the iterator a2: int {.closure.} =
try:
yield 5
return 5
finally:
echo "A"
try:
# "if true" to disarm the unreachable code error.
# switching to "if false" gives correct output (no "hey iterator")
# since the exception isn't raised
if true: raise newException(IOError, "")
yield 10
except: discard
echo "B"
echo "hey iterator"
for x in a2(): echo x Output:
|
What happened?
Nim Version
Every nim version
Current Standard Output Logs
Expected Standard Output Logs
Possible Solution
unrollFinally
always get overriden in theexcept
branch of the closure iterator transformation, but here it should staytrue
.The text was updated successfully, but these errors were encountered: