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

"Reporter didn't report" error isn't catchable #3327

Open
brianharvey opened this issue Mar 9, 2024 · 4 comments
Open

"Reporter didn't report" error isn't catchable #3327

brianharvey opened this issue Mar 9, 2024 · 4 comments

Comments

@brianharvey
Copy link
Collaborator

untitled script pic (2)
untitled script pic (3)

(By the way, if I leave out the MOVE block, then BAD REPORTER reports 0 instead of not reporting. I think that's a bug, too, but less important.)

The reason is this, in threads.js:

Process.prototype.expectReport = function () {
    this.handleError(new Error("reporter didn't report"));
};

which I think should be

Process.prototype.expectReport = function () {
    throw new Error("reporter didn't report");
};

... but when I try that, it causes an infinite loop, so I'll let someone else debug it. :)

This sounds like a minor problem, except that it's standing in the way of the logic programming library development. :(

@jmoenig
Copy link
Owner

jmoenig commented Mar 9, 2024

Error catching isn't part of Snap's functionality, only throwing errors. We don't (yet) have first class exceptions, not even first class processes/threads.

@brianharvey
Copy link
Collaborator Author

brianharvey commented Mar 9, 2024

Aw, c'mon, we advertise a library for it. I don't recall you objecting to that one, although I may be forgetting. Anyway, it's just this one error that we can't catch. That ought to be fixable.

PS We don't have first class processes, exactly, but we do have first class continuations, which sort of comes to the same thing.

@jmoenig
Copy link
Owner

jmoenig commented Mar 9, 2024

Why do you need to catch it, could you explain? You're not using metaprogramming to ad-hoc define new reporters, or are you?

@brianharvey
Copy link
Collaborator Author

Actually one of qw23's goals is to avoid metaprogramming.

The goal is to build something like mapreduce's mapper function, which can return multiple values, including the case of no values, in which case that input is dropped from the result.

Ideally the user would be enabled to insert any expression, such as ddd0b14073eaf5c54c0c565d440c5a8b2359f54e or 26ac7d3691c1268253b6774dbd8fd2e0a18e825f. The latter, however, always reports something (i.e. the value of the input). I tried a special version if (condition) then (expression), not reporting anything if the condition fails. However that causes an error (“hmm ... reporter didn’t report”) that can’t be caught by safely try … any suggestions?

If you want more context, you can start here: https://forum.snap.berkeley.edu/t/logic-programming-library-development-log/13828/108 starting in the middle of that post with the heading "Multiplicate stream items." But it's a pretty long thread, even just the part leading up to this issue.

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

No branches or pull requests

2 participants