What is that error?
gives the answer immediately
doesn't give the answer
gives the answer immediately
gives the answer very slow
made own block to work with append
Okay so, it turns out that my custom version of "all but first" works 2 times faster
Primitve version:
Custom version:
This is a JavaScript error. The list is too long.
Yeah but it seems to appear in all but first + append combination
The ALL BUT FIRST block might use some kind of form of recursion, but I'm not sure.
I believe ALL BUT FIRST is converting from array to linked list, which takes 𝜽(length of list) time. And is implemented recursively.
May I suggest that error messages like this include a link to an explanation page. I've been seeing more and more systems doing that with error messages.
Error handling needs a ton of work.
Your suggestion is a good one, although in some cases, including this one, the explanation would be long and complicated, because there can be many reasons for a stack overflow. So it'd be better, I think, to do a little code analysis and give a targeted error message for each detectable case, e.g., MISSING BASE CASE, or BASE CASE DOESN'T STOP THE BLOCK, or whatever it might be.
this is a JS-Error message, not ours.
I know it comes from JS! But any message we display to users is our message, by definition, wherever it came from.
yeah, but that's not helpful. Since it's not our error we cannot give an explanation, and we cannot "link to a web page with an explanation". We can either pass the message along that we're getting - which is what we're doing - so users can at least get some kind of hint, or we can cloak it up and just say - like others do - "an error has occurred". Which do you like better?
I have to say, this infatuation about being able to "learn something" from reading error messages doesn't convince me one bit.
um guys, the error conversation is cool but, what about the thing, can it be fixed?
You already did!
I reject that dichotomy. As I said,
Thanks to Alan Turing, we know that this sort of analysis can't be done in every case, but I claim that in probably 90% of the cases that come up in actual user code we could figure out what the user isn't understanding and give a targeted error message. And this particular error (stack overflow) is, I think, unusual in that there are several possible misunderstandings. More commonly, I claim, there's only one plausible meaning of an error. And indeed, one by one you've replaced some hideous JS messages with understandable ones.
P.S. Code analysis is complicated and slow. Luckily, we don't have to do it until an error happens.
JS doesn't expose that kind of introspection, you cannot analyze the callstack in JS. Also, contrary to other PLs JS doesn't have standardized error codes. So, no, we simply cannot tell you why some JS error happened.
No, sorry, maybe I expressed myself badly. I don't want to analyze the stack itself. I want to analyze the script that died. So, for example, we should be able to tell that a custom block is recursive, and that there's no path through it that avoids making a recursive call. In fact, we could probably look for specific patterns such as IF (IS input list EMPTY?) [REPORT (LIST)], and if we don't find one, we'd be pretty confident that we understand the error.
It's not like it's only my problem tho, it will reflect on everyone using that combination, and they probably won't know about my solution. Btw, why ALL BUT FIRST works like linked list and not just like a new array? I mean, is there any reason behind that? It looks to work slower
