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

SAFELY TRY changes error messages, doesn't catch them #3346

Open
brianharvey opened this issue Apr 28, 2024 · 3 comments
Open

SAFELY TRY changes error messages, doesn't catch them #3346

brianharvey opened this issue Apr 28, 2024 · 3 comments

Comments

@brianharvey
Copy link
Collaborator

I was trying to use SAFELY TRY to catch errors thrown with the ERROR command, but that didn't work, so I tried experimenting to see if I could catch any errors. I couldn't catch ones with our own error messages, such as "expecting an X but got a Y," so I tried to see if I could catch Javascript's errors, so I was just clicking random blocks to see what error I got. Here are some results:

Screenshot 2024-04-27 at 7 27 23 PM
Screenshot 2024-04-27 at 7 27 45 PM
Screenshot 2024-04-27 at 7 28 41 PM
Screenshot 2024-04-27 at 7 29 53 PM

It was hard to find examples, because hardly anything counts as an error any more, especially since we have hyperblocks. But that's a side comment; the point is, I want to be able to catch errors, and ideally the error caught should be the same as it would have been without catching errors.

Yes, I'm sure I can find a way to kludge around this, and I guess I will for the streams library, but catching errors should work, even though you said in #3327 that it's not supported. So I guess you can call this a new feature request. :~)

@jmoenig
Copy link
Owner

jmoenig commented Apr 28, 2024

This makes me mad.

We do NOT have first-class exceptions and I will NOT implement them any time soon.

The idea to override my handleError() function with some hot-patched shit was one of the "clever" forum kiddie things that used JS functions to modify my Snap evaluator on the fly with stateful tweaks. I did not ever and do not now wish to support any of this horrible stuff. All these little clever tricks that these geniuses come up never see the big picture and tweak little local things to kluge around some particular use case irrespective of the overall design. I'll take out the "catch errors" library for v10. I've had enough of this.

And since you're complaining about this I'll also remove the extension primitives that deal with error handling. Really, Snap's evaluator is a well defined, stable system, and I'm sick and tired of assholes fiddling around with it, and those those fiddlings suddenly turn it "issues" and "bugs" and "feature requests".

@ego-lay-atman-bay
Copy link
Contributor

Catching errors is a good thing for programming languages. It's a way for the program to fail gracefully with user input. It has really become very useful for some things that cannot be detected without errors. I think the best thing for you to do, would be to remake it in a way that you approve, rather than using some kludged script from a forum user.

@brianharvey
Copy link
Collaborator Author

First of all, Jens, if I remember correctly, this library was contributed by Debbie Servilla, who is not an asshole, and it makes me mad for you to categorize her that way.

I think I'll continue my response by email.

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

No branches or pull requests

3 participants