Wrox Programmer Forums
|
BOOK: Professional JavaScript for Web Developers 2nd edition ISBN: 9780470227800
This is the forum to discuss the Wrox book Professional JavaScript for Web Developers, 2nd Edition by Nicholas C Zakas; ISBN: 9780470227800
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional JavaScript for Web Developers 2nd edition ISBN: 9780470227800 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old November 5th, 2010, 03:52 PM
Registered User
 
Join Date: Nov 2010
Posts: 3
Thanks: 2
Thanked 0 Times in 0 Posts
Default Usage of try-catch

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 November 5th, 2010, 07:40 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

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???
The Following User Says Thank You to Old Pedant For This Useful Post:
aoskam (November 6th, 2010)
 
Old November 5th, 2010, 08:02 PM
nzakas's Avatar
Wrox Author
 
Join Date: Dec 2004
Posts: 217
Thanks: 0
Thanked 5 Times in 5 Posts
Default

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.
__________________
Nicholas C. Zakas
Author, Professional JavaScript for Web Developers (ISBN 0764579088)
http://www.nczonline.net/
The Following User Says Thank You to nzakas For This Useful Post:
aoskam (November 6th, 2010)
 
Old November 6th, 2010, 04:57 AM
Registered User
 
Join Date: Nov 2010
Posts: 3
Thanks: 2
Thanked 0 Times in 0 Posts
Default

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
 
Old November 6th, 2010, 03:30 PM
nzakas's Avatar
Wrox Author
 
Join Date: Dec 2004
Posts: 217
Thanks: 0
Thanked 5 Times in 5 Posts
Default

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.
__________________
Nicholas C. Zakas
Author, Professional JavaScript for Web Developers (ISBN 0764579088)
http://www.nczonline.net/
 
Old November 6th, 2010, 05:35 PM
Registered User
 
Join Date: Nov 2010
Posts: 3
Thanks: 2
Thanked 0 Times in 0 Posts
Default

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





Similar Threads
Thread Thread Starter Forum Replies Last Post
about the usage of ant wangpan J2EE 5 June 12th, 2007 06:57 AM
New keyword Usage John Pennington Beginning VB 6 4 August 8th, 2006 10:39 PM
CONTAINS keyword usage caterpillar SQL Server 2000 2 July 12th, 2006 01:19 PM
Software usage [email protected] C++ Programming 0 October 15th, 2004 06:30 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.