What's in *your* Javascript try-catch blocks?
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.
Continue reading "What's in *your* Javascript try-catch blocks?"»
Comments & Feedback
Continue reading "Comments & Feedback"»
Leave logging statements in your production code
- No changes to your code: you shouldn't have to comb through your code to remove or comment out your logging statements.
- Negligible performance impacts: your "productionized" code shouldn't suffer any performance impacts for having the logging system in place.
- Negligible page weight impacts: likewise, your productionized pages should incur a negligible page weight penalty for including the logging code.
- Easy troubleshooting in production: once you are in a production environment, you should be able to easily re-enable logging output, to troubleshoot in a pinch.
With JSLog you can leave your logging statements in, even in production code. Here's how to do it:
1. Quick and Easy: Disable JSLog site-wide via a configuration setting
Impact: the logger panel will no longer be visible, and you can leave all of your JSLog calls in your code. The calls become nullops, so the runtime penalty is negligible. However, your users will still be downloading the 6K jslog.js file.
Need to revisit your logging output? If you need to make the debugging panel visible on a page-by-page basis, you can include the string "enablejslog" in the url. Example: http://localhost/mypage.do?foo=bar&enablejslog. Including the string "enablejslog" overrides the "config_enabled=false," and you can see any JSLog output the page generates.
2. Production Grade: Replace the jslog.js file with a stub
Replacing the jslog.js file with a stub makes both the page weight and performance impacts of leaving your logging statements in your code negligable. Here's how:
A) rename jslog.js to jslog_real.js. The jslog_real.js file will continue to contain the full 6K JSLog implementation, but it will no longer be included in your pages because it has been renamed.
B) create a new jslog.js file with the following:
var jslog = {debug:function(){},info:function(){},
warning:function(){}, error:function(){},
text:function(){}}; var debug=function(){};
if (location.href.match(/enablejslog/)){
document.write('<script type="text/javascript"
src="/includes/scripts/jslog_real.js"></script>');};
The part starting with "if" means you can enalble logging on a page-by-page basis, for example: http://clientsite/page.php?foo=bar&enablejslog, and the stub will dynamically include the real JSLog object, so you can see JSLog output in the JSLog panel as usual. You can leave out the part starting with "if" if you don't need/want that cabability, or just want to save a few extra bytes.
This really gives you the best of all worlds: 1) the ability to leave your logging statements in your code, even as you deploy it to a client; 2) negligible performance impact of leaving the logging statements in; 3) negligible impact on page weight for everyday use; 4) immediate access to the JSLog output if you need to troubleshoot in the production environment.
Recap
JSLog can be part of your strategy as your Ajax code matures from development to production. Even when your code is ready to be fully productionized, it's often helpful to leave your logging code in, for two reasons: 1) it's a pain to remove it, and you can inadvertently introduce errors in your code just be remove logging statements; 2) there is no such thing as code that is completely "done!" At some point you will need to go into that code and make changes, and go through another round of debugging/testing/deployment -- and when you do, it will help to have the logging and debugging statements there.
The configuration setting to turn of JSLog output (by making all JSLog calls null ops) is one easy way to productionize your code without having to remove your logging statements. If pageweight is a concern, you can replace the jslog.js file with a 133-byte stub, which can easily be swapped out if you need to troubleshoot your code. Furthermore, with one additional line of code in the stub file, you can provide the ability to dynamically include the JSLog functionality by typing "enablejslog" in any url. You can use this to help troubleshoot code even after it has been deployed in a production environment.
Continue reading "Leave logging statements in your production code"»
JSLog FAQ
Why doesn't it persist messages between pageviews?
The short answer is that for my purposes, I haven't had the need for it to do so. For all the programming I've been doing, a pageview is the right duration for relevancy of the logged messages.Originally, I envisioned it with two modes: first, a display panel, with no persistence between pageviews (as it is now); second, a "persistant logging" mode, in which logged messages would be sent back to the server via XMLHTTP, and persisted in a database table. A separate page would poll the database and provide the "log viewer," complete with filters for date, severity, and IP/machine name of the browser where the message was logged. However, when I got as far as I did, I realized I had an extremely useful tool which I was using all the time. Honestly, I'm not sure how much more I would use the persistent log mode, if I created it. In addition, it would make it more complex to deploy and use (would have to make sure the DB was there, etc.), so in terms of a lightwight, reusable, easy-to-deploy tool, it's better as-is.
All that said, let me know if you think the persistent logging mode would be useful.
This doesn't use XMLHTTP! How can you say it's an AJAX logging tool?
Because it's most useful when you're creating AJAX applications. Stringly speaking, the technologies used in JSLog itself are pre-AJAX (if you consider XMLHTTP to be the prime enabler of AJAX), i.e., it's really a DHTML application.OK I'm using it. Why can't I drag the logger panel?
You need to install the script.aculo.us libraries for drag and drop to work. And for Scriptaculous, you need Prototype. Both of these are extremely easy to install.
If you haven't experimented with these libraries, you're in for a treat -- they are great tools for AJAX programming.
What version of Scriptaculous do I need?
JSLog is currently working with Scriptaculous version 1.6.1 and Prototype version 1.5.0_rc0. Earlier versions of scriptaculous should work, although I have seen some sketchiness with drag and drop on some versions.I'm getting this error:
Most likely you have an older version of Scriptaculous, and updating to the latest version will solve the problem. If not, drop me an email at andre{at}earthcode{dot}com, and I will try to fix the problem!
Nice tool! Can I use it in my commercial project/environment?
Yes you can -- JSLog is available for use under a BSD-style license. Please drop me an email at andre{at}earthcode{dot}com, and let me know you are using it.
Continue reading "JSLog FAQ"»
JSLog Example
You can try out JSLog right here on this page
Continue reading "JSLog Example"»
JSLog - a Lightweight Ajax logger
What JSLog looks like
When collapsed, it sits unobtrusively in the upper left-hand
corner of the page like so: 
When expanded, it looks like this:
Why you should use JSLog
Every language needs a System.out.println() or a Console.writeLine() -- a quick and easy way to output messages to you, the developer, during development and testing. Historically, Javascript programmers have used alert() for this purpose. The problems are:
- alert() forces you to acknowledge each message, which makes it very bad for debugging things like loops and mouseovers
- there's no graceful way to begin "productionizing" your code when it has a bunch of alerts() in it -- you have to go through and delete all the alerts or comment them out
- alert() notifications are incredibly intrusive, and while they are there in your code, it's impossible to ignore them
- once you acknowledge an alert() box, it's contents are gone and you can't refer to it again
Continue reading "JSLog - a Lightweight Ajax logger"»