Usage of try-catch

aoskam · November 5th, 2010, 03:52 PM

Nicholas, on page 310 of chapter 10 (The Document Object Model) a try-catch statement is used to serve dynamic styles to different browsers:

Code:

var style = document.createElement("style");
style.type = "text/css";
try {
	style.appendChild(document.createTextNode("body{background-color:red}"));
} catch (ex) {
	style.styleSheet.cssText = "body{background-color: red}";
}

The code in the catch portion of the statement is served to IE, because it wonât allow access to child nodes of a style element. Does this usage contradict the advice given on page 477 of chapter 14 (Error Handling and Debugging)?

Quote:

Itâs not appropriate to use a try-catch statement if you know an error will occur with your code specifically.

Is this one of those grey areas or would an if-else statement in this case be a better solution?

Code:

var style = document.createElement("style");
style.type = "text/css";
if (style.styleSheet) {
	style.styleSheet.cssText = "body{background-color: red}";
} else {
	style.appendChild(document.createTextNode("body{background-color:red}"));
}

Thanks for teaching me a lot about JavaScript.

Old Pedant · November 5th, 2010, 07:40 PM

The only reason you would use try...catch for this situation would be if it is possible for the if () to fail *or* to succeed incorrectly.

In other words, suppose that

Code:

if ( style.styleSheet )

returns a non-null value in some browser other than MSIE and yet the line

Code:

    style.styleSheet.cssText = "...";

would perhaps fail in that other browser.

If that's never the case, then clearly the "if" version is more efficient.

**********

FWIW, I personally abhor code such as

Code:

if ( style.styleSheet )

I *MUCH* prefer to write

Code:

if ( style.styleSheet != null )

I know they mean the same thing, thanks to the sloppiness of JavaScript, but they don't have the same "feel". I think that if() tests should always be based on boolean expressions. For the same reason, I detest code that does:

Code:

var i = 7;
while ( i ) {
    ...
    --i;
}

What does it cost to use

Code:

while ( i != 0 )

or

Code:

while ( i > 0 )

which are *SO* much more clear in meaning???

nzakas · November 5th, 2010, 08:02 PM

Strictly speaking, this is not a contradiction. My words were "your code". In this case, it's not your code that's throwing the error, it's the browser's code (appendChild). The point of my statement was to say you shouldn't write code that throws errors just so they can be caught. If there's a condition you can detect, you should.

The purpose of the code in question is so that you use the standard way of accomplishing the task first and fall back to the non-standard way. Just because a browser supports styleSheet doesn't mean the standard way will fail.

aoskam · November 6th, 2010, 04:57 AM

Thanks to both of you for your quick replies and thank you Nicholas for clarifying the separation between âyour codeâ and âthe browserâs codeâ which seems obvious now.

Would a nested try-catch statement also be an alternative for the if statement in the cross browser event handler on page 374? Possibly combined with the lazy loading technique (page 593) to prevent the less efficient catch portion from being used for each event handler thatâs added or removed?

Anne

nzakas · November 6th, 2010, 03:30 PM

I wouldn't use a try-catch for the event handler situation. This is pretty easy to detect just checking for the functions. Generally speaking, if you test for a function and it's there, you can assume it works the way it should. The reason why I used a try-catch for the styles example is because the method doesn't behave the way it should, and it's impossible to detect that without actually executing code.

aoskam · November 6th, 2010, 05:35 PM

Thanks again for your reply. Like in your book you explain the concepts of the language really well and concisely.