Menu
First I'll state what I am trying to achieve: I'd like to have some code that connects to my server via websockets. I send messages to the browser to tell it to reload, remotely. I'd like this code (barring it has no errors itself) to not be affected by other page errors, so that I can still hard refresh the page remotely to fix said errors.
In my testing on latest Chrome and iPad safari, if a runtime exception occurs in one script tag, that js execution halts. However, any other javascript in other script tags still runs no problem. Is this expected behaviour, or am I just getting lucky? I've thrown TypeError's, throw new Error('something'), and undefined errors, and my other scripts still run fine. I do something like so:
<script type='text/javascript' src='reloadCode.js'/>
<script type='text/javascript' src='mainApp.js'/>
If I throw a bajillion errors in mainApp.js, my websocket code still runs and refreshes the page in reloadCode.js, even if mainApp.js is evaluated first.
750
Ok I just did a test myself to make sure, (I don't think separate JS files should mess each other up from compiling)
I first created a simple HTML page which included 3 JS files. Here are the JS files
myscript1.js
alert("1");
myscript2.js
alert("2")a;
myscript3.js
alert("3");
Html
<html>
<body>
<script src="myscript1.js"></script>
<script src="myscript2.js"></script>
<script src="myscript3.js"></script>
</body>
</html>
myscript1 and myscript3 are ran, but it doesn't run myscript2 because of an error, so as long as your reloadCode.js works fine then you will be all A-OK
Just to be clear I only got 2 alerts, not 3, this is because myscript2.js did not compile.
81
Unless they are interacting between them... Then yes they are separated from each other.
25
Adding to the tests in previous answers, it seems the documentation mentions that all errors in a script tag are scoped to that scriptElement and doesn't affect others on the page. For the parsing stages the handling for this is as follows:
If the script's script is null for scriptElement, then fire an event named error at scriptElement, and return.
If the previous step failed, queue a task to fire an event named error at the element, and return. Otherwise, let url be the resulting URL record.
If the script's script is null for scriptElement, then fire an event named error at scriptElement, and return.
The browser should, once a runtime error has been detected in a script, emit an error event on the target scriptElement. If this event is not handled then the browser forwards the error to the developer console.
The error event has the following interface:
interface ErrorEvent : Event {
constructor(DOMString type, optional ErrorEventInit eventInitDict = {});
readonly attribute DOMString message;
readonly attribute USVString filename;
readonly attribute unsigned long lineno;
readonly attribute unsigned long colno;
readonly attribute any error;
};
The behavior for handling runtime script errors is:
When the user agent is to report an exception E, the user agent must report the error for the relevant script, with the problematic position (line number and column number) in the resource containing the script, using the global object specified by the script's settings object as the target. If the error is still not handled after this, then the error may be reported to a developer console.
Source: https://html.spec.whatwg.org/multipage/webappapis.html#runtime-script-errors
30
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
