Skip to content
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

Should body results of loop constructs return the raised error? #1149

Open
hostilefork opened this issue Jun 10, 2023 · 0 comments
Open

Should body results of loop constructs return the raised error? #1149

hostilefork opened this issue Jun 10, 2023 · 0 comments
Labels

Comments

@hostilefork
Copy link
Member

hostilefork commented Jun 10, 2023

At one time the mechanics were such that body execution would be able to make it so that a raised error as a body result would come back as the result of the overall operation. For instance, here was the behavior of REDUCE-EACH:

>> ^ reduce-each x [1 + 2] [raise "foo"]]
== ~make error [
    type: ~null~
    id: ~null~
    message: "foo"
    near: [raise "foo" **]
    where: [raise do console]
    file: ~null~
    line: 1
]~

But conceptually, the suppression of promotion to failure should probably only be applied if it was the last iteration...otherwise a raised error might be missed. e.g. semantically we shouldn't run the 10 + 20 here and suppress the raised error:

>> ^ reduce-each x [1 + 2, 10 + 20] [if x = 3 [raise "foo"] else [x]]
** Error: foo

Returning a raised error as an "early return body result" may be a possibility, but seems dubious.

Hence the current behavior is that loops do not consider errors a viable final return result...but this raises some questions on how compositions like FOR-BOTH which generically META and UNMETA their arguments handle this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant