What's in *your* Javascript try-catch blocks?
Jan 4, 2006 by
Andre
For me, one of the best things about the Ajax movement is that it has legitimized usage of the Javascript language, which I have always enjoyed programming in anyway. With JS's new legitimacy comes recognition that we need more of the "real-world" constructs and practices that we all apply to other languages. Like Logging. And better error handling.
And try-catch blocks.
Which brings us to the question, what's in your try-catch blocks? What are you doing when you catch an error?. In some cases you want to take some specific action (redirect the user to another page, show a clear user-visible error, tell the user there's no point going on, etc.), but in other cases there's nothing you can really do for the user -- you just want to record the error so you can debug the problem as quickly as possible. If this was Java, PHP, Ruby, C#, or whatever, you would log an error and that would be that.
With Javascript, you can use JSLog, and log an error in your catch block. The code looks like this:
Which in turn would give you a JSLog display of:
This works great during development, when you probably have JSLog enabled, and are using it for debugging output anyway. As your code matures into production, you can leave the jslog.error() call there, even as you disable JSLog. If the page is behaving unexpectedly, you can temporarily expose JSLog output (either by switching the config_enabled setting back to true, or by including &enablejslog in the url; see here for details) and see the problem as it was logged in the catch block.
Basically, the problem is that output from the catch block needs someplace to go. JSLog gives it someplace to go, where it can be easily retrieved and inspected, in either a development or production environment. Read more about JSLog here.
And try-catch blocks.
Which brings us to the question, what's in your try-catch blocks? What are you doing when you catch an error?. In some cases you want to take some specific action (redirect the user to another page, show a clear user-visible error, tell the user there's no point going on, etc.), but in other cases there's nothing you can really do for the user -- you just want to record the error so you can debug the problem as quickly as possible. If this was Java, PHP, Ruby, C#, or whatever, you would log an error and that would be that.
With Javascript, you can use JSLog, and log an error in your catch block. The code looks like this:
try {
var foo = somethingRisky();
} catch (e) {
jslog.error("Something risky failed! foo="+foo+"; error is "+e.message);
}
Which in turn would give you a JSLog display of:
This works great during development, when you probably have JSLog enabled, and are using it for debugging output anyway. As your code matures into production, you can leave the jslog.error() call there, even as you disable JSLog. If the page is behaving unexpectedly, you can temporarily expose JSLog output (either by switching the config_enabled setting back to true, or by including &enablejslog in the url; see here for details) and see the problem as it was logged in the catch block.
Basically, the problem is that output from the catch block needs someplace to go. JSLog gives it someplace to go, where it can be easily retrieved and inspected, in either a development or production environment. Read more about JSLog here.
