Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
1  
Why do you think the button being clickable has anything to do with your Javascript script? – Yannis Jul 16 at 9:20
    
@Yannis Yes, you are correct. I must have said the call handler executing instead. – vin Jul 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 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 at 10:21
    
@vin yeh I'm not sure if exceptions are used much in javascript, indeed a lot of error conditions are just ignored since, as you've found, the browser just carries on. Not a good way to go, but it's the way its done. If you're having trouble with that in javascript, you've got a lot more fun ahead of you :-) – daven11 Jul 16 at 11:26
up vote 3 down vote accepted

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.

share|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 at 11:19
2  
@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 at 11:24
    
But it would have been a valuable tool for developers, which would ultimately benefit the users. – vin Jul 16 at 17:59
1  
@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 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 at 18:56

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.

share|improve this answer
    
Aha! But won't it be intuitive to stop the script? – vin Jul 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 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 at 9:55

The JavaScript event handler is 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.

share|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 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 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 at 10:27
    
@vin: what exactly do tou find inconsistent? – JacquesB Jul 16 at 10:45
    
that one terminates and the other doesn't while using very very similar syntax, terminologies and ideas. – vin Jul 16 at 10:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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