Feedback on: irt.org FAQ Knowledge Base Q503
Worth:
Worth reading
Length:
Too short
Technical:
Not technical enough
Comments:
Javascript and JScript are almost exactly the same, when writing serverside script (ASP JScript) I have found try{ ....}catch(error){error.description + " - " + error.name} to be a useful tool for debugging, and it is great for form validation, your opinion that all runtime errors can be solved by trying stuff ahead of time is flawed, no matter how fool proof something is, a better fool is developed, and encapsulating everything in a try block is great for stopping crashes with no compatible browsers(as long as there is some Javascript functionality)
Comments:
I've been using IRT for years, so thank you for this great resource.
I've been exploring error handling in JavaScript recently, because there is at least one circumstance where it is impossible to check if a particular function will work without if first throwing an error. Because of patches that crack down on cross-frame/site/server scripting, we're finding that a lot of actions that we could take for granted in the past are no longer available. For example, if Frame A points to our domain & Frame B points to our domain, we can communicate seamlessly between them. However, if Frame A navigates away from our domain, Frame B is restricted from finding out anything about that page, including the its new domain, URL, and any other elements that may have possibly been on that page.
If you try to do this, you'll find that you get a permission denied error. It doesn't even check to see if it's possible, IE5.5 just ignores the entire possibility and throws an error.
Ergo, even good coding practices won't be of avail. Error catching may be the only way.