Why don't people write all their JS code inside one big try...catch block? Or even better, tart all your code in one function and initiate your program by calling that function form a try...catch block. Why isn't this the norm? What is the catch?
function allMyJSCode() {
console.log("I can get here");
foo.bar = ""; //accessing property of uninitialized object
console.log("but never here");
}
try {
allMyJSCode();
} catch(error) {
console.log("Error from allMyJSCode: " + error);
}
//I can get here
//Error from allMyJSCode: ReferenceError: foo is not defined
Because once an error occurs, the rest of the code won't be executed, it will go directly to the catch block and ignore code that could be important. You don't want that.
Imagine this scenario:
// Important code #1
// Important code #2
Now, if you group these two together in one giant try...catch and for some reason Important code #1 throws an error then Important code #2 will never be executed and could cause problems, whereas if each of these where wrapped in their own try...catch, then no matter what happens in Important code #1, Important code #2 will be reached and get executed.
Important code #1 could be as trivial as changing the background of an element, and it could prevent the execution of code that handles populating data, sending requests, ...
I'm working on an old-school site adding validation to a form (<form onsubmit="return validate_me();">). However, while I was testing it, a JavaScript exception was thrown, the event continued and changed my test data. If this had happened on a production site, a lot of data could have potentially been accidentally erased.
Is it correct behaviour for an event to continue unimpeded when an exception is thrown? I would have assumed that an explicit true would need to be returned for the event to continue. Is there a way to NOT continue an event after an unhandled exception?
The form will submit unless an explicit false is returned from the validate_me() function.
Wrap your whole validate_me function in a try catch block and return false if any JavaScript errors occur in the process like this
function validate_me(){
try{
//do some stuff
} catch(err){
console.log(err);
return false;
}
}
By running the following, you can run code if an error is thrown.
try {
// test
} catch (e) {
// error output
}
Is there a similar way to run code only if no error is thrown?
Sure there is, see the comment inline.
try {
// test
// No error is thrown if program control reaches here
} catch {
// error output
}
Consider using an additional try block in the "No error is thrown" part if you don't want the outer catch to handle any other errors.
I have a $.getJSON() call in my try that is throwing an error, but the catch is not being triggered. Nothing is happening. Just the error in the console.
Why is this?
What I'm trying to do is do something if the JSON is loaded and do something else if there is a failure or error in the request.
Here is my code:
try{
$.getJSON('https://www.googleapis.com/freebase/v1/search?query=&filter=(all+type%3A%22nominated%20works+exhibited_at%3A%222012%20grammy%27s%22)&indent=true', function(searchJSON){
alert('sucesss!');
});
}
catch(e){
alert('failure: '+e);
}
Here is a link to a jsfiddle: http://jsfiddle.net/sgeg56c3/
Your callback function is asynchronous, while your try / catch block is synchronous. By the time your async callback has finished, the try / catch block may have already finished.
Since exceptions are handled synchronously, you'll need to use a different method for error handling.
I recommend reading Asynchronous Error Handling in Javascript
This is a very basic question. In Java I use the finally statement to close resources because "it's a good practice". I've been developing in Javascript and then in Node.js during some years and I've never used the finally statement. I know that in Node.js all of us follow the first parameter error handling pattern. Anyway, the 2 following snippets do the same:
try{
throw 123
}catch (e){
}finally{
console.log(1)
}
.
try{
throw 123
}catch (e){
}
console.log(1)
Both print 1.
Why is finally a keyword if it has no real benefit? The clean up code can be put inside the catch.
finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break.
Just a simple and straightforward example that shows the difference. There is a return that breaks the function completion, but the console.log in finally is called while the last console.log is skipped.
let letsTry = () => {
try {
// there is a SyntaxError
eval('alert("Hello world)');
} catch(error) {
console.error(error);
// break the function completion
return;
} finally {
console.log('finally')
}
// This line will never get executed
console.log('after try catch')
}
letsTry();
But try this:
try {
throw "foo"
} catch (e) {
throw "bar"
} finally {
console.log("baz")
}
console.log("quux")
If a second error is thrown from within the catch block, the code after the try...catch block will not run.
The finally block will always run, even if there is an error in the catch block.
Furthermore, the finally block runs even if a return or break statement stops the code in the try or catch block. return statements in the finally block override return statements in the try or catch block.
function foo() {
try {
return "bar";
} finally {
return "baz";
}
}
foo() // "baz"
oracle docs provide a good answer to this. Bottom line: finally gets called always! Even when you catch only one kind of exception (not the global catch), then finally gets called (after which your application probably breaks if there is no other catch)
the finally block is meant for a special purpose.
finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.
Since it wont effect your business logic,Still it's compiler friendly,In memory aspects.
What if the try-block returns early or throws an exception that you don't handle? You would still want to free the resources you have allocated, right?
EDIT:
The answers to the question seem almost philosphical, there is some 'guessing' and basically 'we believe it should be useful, because it is there, so it should have a use', and 'even Oracle says so'. Or maybe it is there to help the programmer not 'to forget something' or 'accidently exit and not realize it'.
These are almost all valid reasons, but there is also a technical reason.
It helps avoiding code duplication in the cases mentioned, where (a) either the try or one of the catch blocks returns or (b) if within the catch block a second exception is thrown.
In these cases, if some cleanup code or any other code that still needs to be executed after the return and after the second exception, could be placed into the finally block, if it is to be executed both after the try and after the catch block.
You could still do it without the finally block, but the code would have to be duplicated, which the finally block allows you to avoid. This is where you really need it.
So if you are sure you do not miss it as a case of (a) or (b) you could still put the 'finally' code after the try/catch block and omit the finally clause.
But what if the situation changes? When you or another person change the code at some later point it could be forgotten to check if the cleanup code is now skipped in some situation.
So why not always put the cleanup code inside the finally block? And this is what is recommended and what many JavaScript programmers do.
You use it when you want to be sure your code is executed at the end, even if there was an exception during execution :
InputStream is = new FileInputStream("C://test.txt");
try {
//code...
} catch (Exception e) {
//code...
} finally {
is.close();
}
This is a very good question.
There is little to no reason to use finally in javascript, but I can imagine situations where it could be of practical use.
Suppose you have a webpage where you show a certain div after some user action, e.g. button clicked.
The div shows some logging for instance for the action the user requested.
After the action is complete (error or no error), you want to be sure to hide the div again. For that you can use the finally clause.
function doSomething() {
var d = document.getElementById("log");
show(d);
try {
... execute action ...
} catch(e) {
log(e);
} finally {
hide(d);
}
}
In general, as you mentioned, exceptions are less and less used in JavaScript in favor of error callbacks.
So, one could as well ask, what good uses are for exceptions in JavaScript in general.
The problem is with your example. There are cases when you don't want to catch the exception.
try {
if (Math.random() > 0.5) throw 123
}
finally {
console.log(1)
}
In these cases all you could do is rethrowing the exception if you don't want to use finally.
try {
if (Math.random() > 0.5) throw 123
}
catch (e) {
console.log(1)
throw e
}
console.log(1)
or maybe
try {
if (Math.random() > 0.5) throw 123
console.log(1)
}
catch (e) {
console.log(1)
throw e
}
Both alternative solutions lead to code duplication, that's why you need the finally keyword. It is used most of the time to free up unused resources. Forgetting about it may lead to unwanted locks or connections or memory leaks. I guess in some cases even a smart GC cannot prevent it.
In Java, if there's an Exception thrown that is not matched by any of the catch-blocks execution will break and any open resources will be left open.
The finally block will always be executed, even if an uncaught exception occurs.