2

As someone used to C++ and new to JavaScript, I find this behavior odd. Whether a program runs directly on the platform like C++ ones, or it runs at a higher (or deeper?) level like JavaScript ones, conceptually, a program a program and an exception is an exception. Then why does JavaScript have this behavior? Is JavaScript's definition of exception different?

Look at this simple example.

<!doctype html>
<html>
<body>
<button id="throw">Throw Exception</button>
</body>
<script>
document.getElementById("throw").onclick = function(){
throw "Uncaught Exception";
}
</script>
</html>

When the button is clicked, the console displays "uncaught exception: Uncaught Exception" as expected. However, clicking the button again even after this, an exception is thrown, meaning the script execution isn't blocked. Had it been C++, the program would have ended. The fact that it runs inside a browser shouldn't matter because the browser can simply stop the script and notify the user; after all, the browser behaves as the script's platform.

I want to know the reason behind this.

Is there a "The Design and Evolution of JavaScript" kind of book where we can understand why things are the way they are?

|improve this question
  • 2
    Why do you think the button being clickable has anything to do with your Javascript script? – yannis Jul 16 '16 at 9:20
  • @Yannis Yes, you are correct. I must have said the call handler executing instead. – vin Jul 16 '16 at 9:47
  • You may find Crockfords 'Javascript: The good parts' useful shop.oreilly.com/product/9780596517748.do not so much a design and evolution but the parts to use and why. – daven11 Jul 16 '16 at 10:00
  • @daven11 I did check that before asking and it just talks about using good parts well. Exceptions is literally just half a page content. – vin Jul 16 '16 at 10:21
  • 1
    "conceptually, a program a program" - I think this assumption is just fundamentally flawed. Furthermore, the assumption that the C++ behavior is the natural way is also flawed. Delphi, for example, despite being a compiled-to-native language that doesn't run on some platform, catches every exception (including access violations) in the main loop of its windowing library and will try its best to keep the program running, similar to the behavior you observed for JavaScript. – Sebastian Redl Jul 16 '16 at 20:35
10

A major difference between C++ programs and Javascript scripts is that a C++ program typically runs for a much longer time than a Javascript script.
A C++ program with a GUI executes continuously while you are working with the program. A Javascript script on the other hand only executes for a short time to respond to an event and then it ends (even if it doesn't throw an exception).

An uncaught exception in a Javascript script does cause the script to be terminated, but the browser executing the script does not remember that it terminated abnormally. This means that when the button gets pressed again, the browser will simply execute the script again.
In this way, it is fully comparable to you re-starting a C++ program after it has crashed.

|improve this answer
  • An uncaught exception in a Javascript script does cause the script to be terminated, but the browser executing the script does not remember that it terminated abnormally. This means that when the button gets pressed again, the browser will simply execute the script again. In this way, it is fully comparable to you re-starting a C++ program after it has crashed. Can I assume from this that archaic browsers did so as JS was a non entity back then and all modern browsers mimic'd that behavior for "behavioral backward compatibility"? – vin Jul 16 '16 at 11:19
  • 6
    @vin: No, it is not for backwards compatibility. It is primarily because there is no value in preventing a user from restarting a crashed script/program. – Bart van Ingen Schenau Jul 16 '16 at 11:24
  • But it would have been a valuable tool for developers, which would ultimately benefit the users. – vin Jul 16 '16 at 17:59
  • 3
    @vin: For developers, it would probably be counter-productive if they can't re-run a script/program that terminated with an exception. If there is an unexpected exception in a complicated piece of code, it is often useful to reproduce the problem multiple times to see what the exact behavior is and when things start to go wrong. – Bart van Ingen Schenau Jul 16 '16 at 18:09
  • 1
    @vin: But the script does terminate and fail fast. I'm not sure what you are looking for, but a script that is attached to a button will not be executed until/unless the button gets pressed and then the script either runs to completion or terminates in some other way. – Bart van Ingen Schenau Jul 16 '16 at 18:56
2

That's not true at all. The JS exception is not uncaught in the slightest. It's simply caught by the browser. A C++ UI library can trivially produce the same effect by calling the onClick handler inside a try/catch.

The difference in behaviour has nothing to do with language - it's all library.

|improve this answer
  • Aha! But won't it be intuitive to stop the script? – vin Jul 16 '16 at 9:42
  • Sure it would be intuitive. But it's a deliberate choice to go the "on error goto continue"-routine in client-side JS, which is after all for the web with ist many intermittent error-sources, and was at first thought to be only for small gimmicks, not serious business applications. – Deduplicator Jul 16 '16 at 9:47
  • @Deduplicator You mean, as the toy became something more serious the features remained as they were and not adjusted for wider usage? – vin Jul 16 '16 at 9:55
2

The difference is not in the languages but in the execution environment. The fundamental difference is you are running C++ as a stand-alone program. This means an uncaught exception will terminate the program. Exactly the same will happen if you run a JavaScript program as a stand-alone script and there is an uncaught exception.

But you are comparing a stand-alone program with embedded JavaScript running in the browser. This works different since embedded JavaScript is not a single program in itself.

The JavaScript event handlers are executed by the browser engine which also handles rendering of CSS/HTML, user interaction, network traffic and so on. When the engine executes an event handler, uncaught exceptions in the JavaScript code terminates the execution of the event handler code, but does not terminate the browser engine, since this would mean a script on web page could cause the browser to crash.

It is a core feature of exceptions that they can be caught and handled (or ignored) at any level in the call stack above where the exception is thrown. You can do the same thing in C++ with try/catch.

It seems you suggest "the script" as a whole should be terminated, that is, all JavaScript on the page should be disabled. But this is not really how exceptions work. Exceptions travel upwards in the call stack, not "sideways". JavaScript event handlers are invoked by the browser engine, which means unhandled exceptions should theoretically travel up and cause the browser engine to terminate. But if exceptions are caught and handled, there is no reason that other event handlers should be affected.

|improve this answer
  • I am unaware of browsers implementations, but from what you say I imply that browsers run all the scripts from all pages on one engine. If that is correct, instead of terminating the engine, scripts from a particular page could be blocked. Isn't that possible? Or was it seen as unimportant and over engineering back then and the legacy behavior is retained? – vin Jul 16 '16 at 10:04
  • @vin: At least Firefox have the option to disable all scripts on a page if one event handler takes too long to execute. This is to prevent browser hanging due to a slow script or infinite loop. But I don't think an exception in a single event handler should cause all scripts on the page to be disabled, that does not really seem like a useful or logical behavior. – JacquesB Jul 16 '16 at 10:19
  • Yes, throwing exceptions must not disable the script, but not doing so even for uncaught exceptions creates confusion and inconsistencies when working with multiple languages. This is exactly what I want to understand, why it is like this. – vin Jul 16 '16 at 10:27
  • @vin: what exactly do tou find inconsistent? – JacquesB Jul 16 '16 at 10:45
  • that one terminates and the other doesn't while using very very similar syntax, terminologies and ideas. – vin Jul 16 '16 at 10:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.