No it's not flawed, but for synchronous code it's typically easier and cleaner to check things with your own code than use a clunky try{}catch(e){}.
example:
var container = document.getElementById("timmy");
container.innerHTML = "I'm timmy!";
If there's no element whose ID is "timmy", we can handle that either like this:
try
{
container.innerHTML = "I'm timmy";
}
catch (error)
{
//handle no container
}
or:
if(container) container.innerHTML = "I'm timmy";
else //handle no container
Another thing to keep in mind is JavaScript applications are event-driven and try/catch blocks in the main part of your program can't catch errors that occur in event callbacks.
example:
sqlConnection.query("SELECT * FROM table",
function(){console.log("queried!");});
that will trigger some native code that runs as your program continues. If an error occurs, you can't expect your program to back-track up to this line so your error handler can do its stuff! Instead, you handle errors in the call-back itself. It is common practice to provide callbacks with any error that occurred by passing it as the first parameter.
sqlConnection.query("SELECT * FROM table",
function(error, data){
if(error) console.log("query failed");
else console.log("queried!");
});
Alternatively, if your code fails in a callback, you can handle it the way I mentioned above.
link.onclick = function(e)
{
var popUp = document.getElementById("popup");
if(!popUp)
return true; //follow link if no pop-up exists
popUp.style.display = "block";
};
