why is error in Javascript internal/external file stops the below code too?

Question

The Error in JavaScript internal/external file also stops the below code

For example:

var myObj = {};
myObj.other.getName = function(){
  console.log('other is not defined');
};
alert('this will not show');

in above code, the alert will not come as the above code has error.

I added the same code in one file tst1.js and below this add one more file tst2.js. put alert('in tst2.js') in it. the tst2 alert come while tst1 not. it is some what related to code compilation/interpretation.

It's much appreciated If someone explain me this behavior :)

Answer 1

This is the default behaviour of JavaScript. Avoid errors and the code will run normally. Also you can handle errors with try...catch : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch

Answer 2

All JS implementations are, AFAIK, single threaded. This means that all of your code is executed sequentially, on a single thread (logically). If this thread encounters a fatal error, it grinds to a halt. All code that comes after the point where the error occurs is ignored (the JS engine halted, no work is done anymore).
To clarify: it does not matter how many files you have. All of the JS code is stringed together into one big script, and this one script is executed sequentially (execution point starts at line 1 of the first script, and ends at the last line of the last script). Any errors in that code will cause the overall execution to grind to a halt:

//file1.js
var foo = (function()
{
    console.log('This file is flawless, but pointless');
}());
//file2.js
foo();//calls previously defined function, assigned to var foo
//file3.js
fudhfsiufhi;//ERROR
//file4.js
foo();//will never get executed, because an error occurred in file3.js

Remove file3, or indeed fix the error, and everything will work as expected.
Allthough JS code is executed/evaluated sequentially, event handlers, callbacks, intervals, and timeouts might lead you to believe otherwise. Couple that with the fact that you have some control over what code is executed when, but not full control , and you get situations that, at first, seem rather counter intuitive. Consider this:

setTimeout(function()
{
    massive(syntaxError) -123 + "here";
},0);//zero MS
alert('This will show');

This oddity is well documented, but it has to do with JS having a callback/handler loop, and queue. The setTimeout sets a timeout, to call the anonymous function in 0ms (immediately), but that callback is sent to the queue, which is checked periodically. Before the queue is checked (and the callback invoked), the alert will show. That's why the interval you pass to setTimeout or setInterval is not guaranteed to be exactly N milliseconds.
You can postpone a call to a method somewhat, by adding a call to the queue, like in the snippet above. But when the queue is processed, and what order the queued calls will be performed in are things you have no real say in. No say whatsoever.

It doesn't matter how many files, or how many statements that come before or after the problematic piece of code: there is no thread left to carry on.

The code you posted has a pretty clear error in it: you're assigning a property to other (a property of myObj , but this property is not defined anywhere, let alone defined as an object. Fix it by declaring properties first, before accessing them:

var myObj = {other: {}};//other is an empty object literal
myObj.other.getName = function()
{
    console.log('This works');
};
alert('And the alert will show');

Your current code evalutes to:

var myObj = {};//object
var (myObj.other).getName = ...;
     //evaluates to undefined
    undefined.getName = ...//ERROR

undefined is a primitive value, actually signifying the absence of a value. undefined , therefore, cannot be accessed as an object, it can't be assigned properties.

Note:
This is just for completeness' sake, but JS is indeed single-threaded most of the time, but ECMAScript5 introduced Worker 's which allow for some restricted form of multi-threading (without shared state, for example). Read through the MDN documentation on workers if you want to know more.