You hear the term robust thrown around loosely.
"Hey Bob, that new app is gonna be robust, right?"
"Oh yeah Steve, I'm all over that robustness."
But how many people really understand what they're promising? I certainly didn't used to. If you dictionary.com the word robust, you are told that it means strong and healthy. If you try to translate that meaning to software quality, it become a little ambiguous.
Strong. Does that mean the software can process a lot of data? Or can support a large amount of concurrent users?
Healthy. Are we talking about how many errors occur within the software? Health is perhaps more closely related to robustness, but not exactly.
When talking about software, robustness is how well your code deals with errors, and whether or not the software can continue to run in the wake of an error. Using the healthiness analogy: Your software may be in perfect shape and run error free 99.9% of the time, but how well does it cope when it catches a cold? If your software decides who your best friend is on Facebook, no harm done if an error shuts down the program. But, if your software operates a pacemaker, that .1% probability of an error really shouldn't shut anything down!
Different web technologies offer different solutions, some not quite as apparent as others. But, beyond syntax and keywords, there are methodologies that provide robustness. The general approach needs to be a little different when working with client-side code as opposed to server-side. On the server side we have more complete error information, as well as logging and notification options that just aren't possible (or are more much more difficult to achieve) on the client side.
On the server side, the first step is to decide what the barricade protects. For instance, if you have a two-column website in which both columns are dynamically generated by your server-side code, you might want the content column to be entirely unaffected by any errors that occur in the sidebar. A popular example of this issue occurs within any given WordPress blog. Depending on your PHP error settings, an error in your sidebar will "take down" the entire page. With this possibility, it's in your user's best interest to barricade the sidebar from the rest of the site. For that matter, perhaps the footer as well.
We can do this with our old friend the try/catch block. By wrapping the entire sidebar code in a try/catch, we prevent any and all errors from affecting the rest of the site. This still allows our more "fine-tuned" errors to do their job of properly logging and notifying the user of any errors. But, we also have the added comfort of being able to log errors from within the "master" catch block.
This doesn't even mention the level of security gained by not exposing error information to potential hackers.
So, how is this useful?
var x = something; // 'something' is not defined
document.write('Why won\'t my message display, sadness');
document.write('I am unscathed by the errors in my document\'s other script tag!');