 | ||
|
| ||
| ||
|
| ||
Michael Wallent
Lead Program Manager, DHTML
Microsoft Corporation
October 1, 1997
The following article was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "DHTML Dude" column.
Welcome to the first DHTML Dude column. I'll be in this spot every month, helping script developers create powerful pages and applications with Dynamic HTML, the new technology in Microsoft Internet Explorer 4.0. Now, let's make no mistake about this month's topic -- error handling.
I fondly remember my days writing Smalltalk code, and how productive that was. It was so intuitive. So easy. So fast.
<a = Dialog new.> <a open.>
Now that was simple.
My buddies down the hall were struggling with their Visual C++ compilers, looking up error code #1863. Not me. No errors in my code. No typos, no type checking. Now that was productivity.
However, when the gods (and goddesses) of the test team came calling, they still seemed to visit me quite often. Seems the problem was these crazy dialogs, which no one understood, that kept popping up: "Member not found." Then the program would stop working. It wasn't that writing in Smalltalk was any harder than writing in C++. In fact, it was easier. However, for each of the coding issues that were caught by the compiler, I got a runtime error in my code.
Does any of this sound familiar yet?
Smalltalk, like JavaScript and Visual Basic Scripting Edition (VBScript), was an interpreted, late-bound language. The not-so-user-friendly interpreter failed to catch errors that the friendly C++ compiler would catch. Unfortunately, this would happen while customers were actually trying to use the product. This was not good.
Building solid code in a late-bound world poses a special set of problems that some of you may not have encountered yet. Also, the Web poses the additional complexity of asynchrony (things may not download when you expect them to).
There are ways to make your code less likely to fail, and other ways to handle errors you didn't expect. We'll take a look at those here.
Try the following HTML:
<html> <body> <script> alert(Absent.id); </script> </body> </html>
Not very nice. Notice the big error dialog that pops up? Try this code instead.
<body>
<script>
var x;
x = document.all["Absent"];
if (x != null) {
alert(x.id);
} else {
alert("Friendly message");
}
</script>
</body>
</html>
Notice that when this HTML runs, the dialog with the "Friendly Message" appears. No runtime error, no loss of control.
The key line here is this:
x = document.all["Absent"];
This line looks up the element with ID "Absent" from the document.all collection. This method will never cause an error. If "Absent" isn't found, then x will be set to null. If it is found, then x will be that element. You could also do the following:
x = document.all.Absent;
But why would an element ever be undefined? In most cases, when your entire application is contained in a single HTML page, that wouldn't happen. The most likely reason for an element being undefined is that the element you are accessing is in another frame which hasn't finished loading. By checking the window.readyState property on the target frame, it's possible to tell the status of the frame. If the value of the window.readyState property is "complete", then you know the entire page has loaded and is ready.
If you are building a page that uses linked style sheets, objects, plug-ins, or applets, you can use the same technique to ensure the presence of all of the objects you expect to be there.
Which brings us to my earlier point about asynchrony. Because Web pages are made up of different components, all of them downloaded separately, you really can't depend on your page parts becoming available to you in a deterministic manner.
When using framesets, linked style sheets, objects, images, plug-ins, or applets, it is very important to first verify that the component has successfully loaded before performing operations that may cause a runtime error.
One of the most common programming errors is a simple typing mistake: simply switching variable names around. Many programming languages will produce an error when an unknown property or variable name is accessed. For those of you using JavaScript, you may already be familiar with a very powerful feature of the language that we call "Expando Properties." Simply put, with Internet Explorer 4.0, a Web author can add arbitrary properties to any element on the page.
For example:
<script> window.myExpando = "We Love Expandos" </script>
This is an extremely powerful feature, one I often use when writing Web pages. However, it can easily mask bugs in your page script. If you choose not to use Expando properties, and want to insure that you have no unintentional instances of them, you can turn the Expando property feature off by setting the document.expando property to false.
Even if you use the most defensive coding techniques possible, sometimes your code will still have an error. To avoid having users see the default error dialog, it is possible to trap the error, and display your own message.
Using JavaScript, its possible to intercept the error by trapping the window.onerror event. You may then perform whatever script you want.
The following code does just that.
<html>
<body onclick="window.causeError();">
HTML Document
<script>
function errorHandler() {
alert("Error Handled");
return true;
}
window.onerror = errorHandler;
</script>
</body>
</html>
Note that in this example the error-handling function returns true. This causes the primary error dialog not to display. If the function returned false, or had no return value, the standard error dialog would appear.
In VBScript, it is only possible to suppress the error dialog -- it is not possible to have your own error handling code run. This is done by inserting the on error resume next directive into the script that you want to trap errors in.
Building Web pages that are fast, easy to use, and error free is a goal all Web developers share. By using defensive programming practices, and -- if all else fails -- error-handling mechanisms, you will give your users a much better experience, and you will get fewer visits from your test team.
Michael Wallent, Site Builder Magazine (now known as MSDN Online Voices) monthly columnist on Dynamic HTML, is Microsoft's lead program manager for DHTML and a connoisseur of the finer things in life, on and off the Web. Some of his best friends are Swiss physicists.
For a comprehensive guide to information on DHTML, from introductory overviews to advanced how-to's, consult the Dynamic HTML pages in the MSDN Online Web Workshop.
Being a veteran DHTML dude, Michael Wallent has already written the book -- or at least a whole bunch of articles -- on the technology. Other subjects he has covered in Site Builder Magazine (now known as MSDN Online Voices) feature articles include:
The DHMTL Object Model
Every month, Site Builder Magazine (now known as MSDN Online Voices) columnist Nadja Vol Ochs explores Web design issues and solutions in Site Lights. And look for in-depth technical articles in the much expanded and redesigned Design section of MSDN Online Web Workshop.
To obtain the final-release version of Internet Explorer 4.0, either by free, online download, or on a CD (nominal shipping charge applies), go to the Internet Explorer 
site.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top