javascript

Chapter 14: Error Handling and Debugging
❑
❑
Chrome — Object name has no method ‘ sort ’ .
Opera — Type mismatch (usually a non - object value used where an object is required).
Although Firefox, Chrome, and Safari at least indicate the part of the code that caused the error, none of
the error messages are particularly clear as to what happened or how it could be fixed. When dealing
with one function, as in the preceding example, debugging is easy enough to handle with these error
messages. However, when you’re working on a complex web application with thousands of lines of
JavaScript code, finding the source of the error becomes much more difficult. This is where a custom
error with appropriate information will significantly contribute to the maintainability of the code.
Consider the following example :
function process(values){
if (!(values instanceof Array)){
throw new Error(“process(): Argument must be an array.”);
}
values.sort();
for (var i=0, len=values.length; i < len; i++){
if (values[i] > 100){
return values[i];
}
}
}
return -1;
In this rewritten version of the function, an error is thrown if the values argument isn ’ t an array. The
error message provides the name of the function as well as a clear description as to why the error
occurred. If this error occurred in a complex web application, you would have a much clearer idea of
where the real problem is.
When you’re developing JavaScript code, take a critical eye towards each function and the circumstances
under which it may fail. A good error handling protocol ensures that the only errors that occur are the
ones that you throw.
Throwing Errors versus try - catch
A common question that arises is when to throw errors versus using try - catch to capture them.
Generally speaking, errors are thrown in the low levels of an application architecture, at a level where
not much is known about the ongoing process and so the error can ’ t really be handled. If you are writing
a JavaScript library that may be used in a number of different applications, or even a utility function that
will be used in a number of difference places in a single application, you should strongly consider
throwing errors with detailed information. It is then up to the application to catch the errors and handle
them appropriately.
The best way to think about the difference between throwing errors and catching errors is this: you
should only catch errors if you know exactly what to do next. The purpose of catching an error is to
prevent the browser from responding in its default manner; the purpose of throwing an error is
to provide information about why an error occurred.
479