Sending a JavaScript interpreter back to the top of your code

Question

Say I have 20 rows of JS code and I want the interpreter to execute only half of the code (<11 rows), then stop, without functions and returns, or without commenting the rest of the code (I already tried a return, see in advance).

A location.reload(true); in row 10 is a close solution but I'm looking for a client side stop.

My question

Is there like a stop command (or functionality) in JavaScript, that asks the interpreter to stop and behave as if no code ran so far?

Why I ask

The background for this question is a problem I have calling a function in more than one keydown event.

Given the keydown event is triggered only once, I consider sending the interpreter back to the start after the keydown event was triggered disposably, and without refreshing the page (Sorry if it seems absurd, I'm new to JS and failed finding the source of the bug).

Of course, the above question is different than the question "why does the keydown event triggered only once", which I already asked here - here's a link for context.

Preventing an XY problem

On one hand, I want to make sure there is no XY problem. On the other hand, I am not allowed to copywrite the previous question to this session hence linked to it above.

Either way, I would be glad to know if what I just described (client side stop of a JS interpreter) is even possible in the current release of the language.

_{Note: I decided to carefully rewrite the question after some comments earlier today (there were no answers) and did my best ensuring the question is informative and communal.}

No, there is no `stop` command, and you shouldn't need one. Fix the underlying problem instead. — adeneo, Sep 04 '17 at 18:08
You can always `throw` an exception, but that won't stop asynchronous code that had already been started from executing afterwards. — Bergi, Sep 04 '17 at 19:24
@Bergi, you mean to `throw dC()` instead `return dC()` but with a catch block right after the closure of the `addEvenetListener`? — user8551674, Sep 04 '17 at 23:40
@adeneo, please see the other thread. I find no solution to the problem. — user8551674, Sep 04 '17 at 23:48
@user8551674 No, for that problem you shouldn't use this at all (also because it *is* asynchronous so exceptions don't help there). I was answering the general question about how to break from a synchronous script. — Bergi, Sep 05 '17 at 01:06
Oh, I should learn on how to recognize what JS codes are causing interpreted data to come back async and what's sync... Right? That's the right way to put it on what I should learn? — user8551674, Sep 05 '17 at 02:09

score 1 · Answer 1 · edited Sep 05 '17 at 20:12

There is no stop command, but I experienced the need of it before when there was a long-running client-side operation.

The solution:

1) Divide the problem into small packets

2) Make sure you are able to make your function work only for activeMilliseconds milliseconds:

function doStuff(packets, currentIndex, activeMilliseconds) {
    var start = new Date(); //Start of chunk
    while((currentIndex < packets.length) && (new Date() - start < activeMilliseconds)) {
        //Do something with packets[currentIndex]
        currentIndex++;
    }
    return currentIndex;
}

3) Now that we are able to work for activeMilliseconds milliseconds, we need to use this asynchronously:

//Define packets
var currentIndex = 0;
var intervalID = setTimeout(function() {
    If(currentIndex = doStuff(packets, currentIndex, activeMilliseconds) >= packets.length) clearInterval(intervalID);
}, totalMilliseconds);

Node: totalMilliseconds > activeMilliseconds should be true. For example, if totalMilliseconds is 250, and activeMilliseconds is 200, then in each 250 milliseconds a chunk will run for 200 milliseconds, leaving the browser to do its stuff for 50 milliseconds every 250 milliseconds even if there is a lot of work to do.

4) Make sure a job stops a previous similar job:

function doJob(packets, intervalID, activeMilliseconds, totalMilliseconds) {
        clearInterval(intervalID);
        //Define packets
        var currentIndex = 0;
        var intervalID = setTimeout(function() {
            If(currentIndex = doStuff(packets, currentIndex, activeMilliseconds) >= packets.length) clearInterval(intervalID);
        return intervalID;
    }, totalMilliseconds);
}

If you use this idea for your key event, then it will stop the previous keyboard, your maximum wait time to do so will be activeMilliseconds, which is an acceptable compromise in my opinion.

That said, this methodology should be only used in the case when you have no other option. You need to know that Javascript has a single thread, so even if you trigger a function execution while a previous instance of the event is still running, your new event will sequentially be executed when the other event is finished.

Thank you dearly Lajos. I tried to fully read the answer twice and took some more looks. I must admit I didn't understand most of it. I don't understand what you aimed to do in regards to keydown of the "D" key and how it differs essentially from my current code. I am much fresher and my JS knowledge is much basic then you might assumed. Please, try to simplify the code example as much as you could with renaming the variables and adding comments. — user8551674, Sep 04 '17 at 23:33
@user8551674 the most important difference is that in my code we keep track of the id of the interval and can stop the repetition using clearInterval. You can trigger the function from your keydown event. I cannot simplify the code without losing quality. I would rather answer to questions to clarify it. — Lajos Arpad, Sep 05 '17 at 17:58

Sending a JavaScript interpreter back to the top of your code

My question

Why I ask

Preventing an XY problem

1 Answers1