-
Notifications
You must be signed in to change notification settings - Fork 750
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
Comments
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 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". |
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. |
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. |
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:
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. :~)
The text was updated successfully, but these errors were encountered: