jmoenig
commented
2 months ago 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
brianharvey
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. :~)