Desktop Consoles

All modern desktop web browsers expose errors through their web console. These errors can be revealed in the developer tools console. In all the previously mentioned browsers, they share a common path to accessing the web console. Perhaps the easiest way to view errors is to right-click on the web page, select Inspect or Inspect Element, and click the Console tab.

To proceed directly to the console, different operating systems and browsers support different key combinations:

Mobile Consoles

Natively, mobile phones will not offer a console interface directly on the device. However, there are several options for you to use in situations where you would like to inspect errors that are thrown on a mobile device.

Chrome for mobile and Safari on iOS come bundled with utilities that allow you to connect the device to a host operating system running that same browser, and you can then view the errors thrown through the paired desktop browser. This involves physically connecting the device and following the setup instructions for Chrome (https://developers.google.com/web/tools/chrome-devtools/remote-debugging/) or Safari (https://developer.apple.com/library/content/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/GettingStarted/GettingStarted.html).

It's also possible to use a third-party utility to debug directly on the mobile device. A commonly used utility for debugging Firefox is Firebug Lite (https://getfirebug.com/firebuglite_mobile). This works by shimming the Firebug script into the current web page using a JavaScript bookmarklet. Once the script runs, you'll be able to open a debug interface right on the mobile browser. Firebug Lite also has versions for different browsers such as Chrome (http://getfirebug.com/releases/lite/chrome/).

The try-catch Statement

ECMA-262, third edition, introduced the try-catch statement as a way to handle exceptions in JavaScript. The basic syntax is as follows, which is the same as the try-catch statement in Java:

try {
 // code that may cause an error
} catch (error) {
 // what to do when an error occurs
}

Any code that might possibly throw an error should be placed in the try portion of the statement, and the code to handle the error is placed in the catch portion, as shown in the following example:

try {
 window.someNonexistentFunction();
} catch (error){
 console.log("An error happened!");
}

If an error occurs at any point in the try portion of the statement, code execution immediately exits and resumes in the catch portion. The catch portion of the statement receives an object containing information about the error that occurred. Unlike other languages, you must define a name for the error object even if you don't intend to use it. The exact information available on this object varies from browser to browser but contains, at a minimum, a message property that holds the error message. ECMA-262 also specifies a name property that defines the type of error; this property is available in all current browsers. You can, therefore, display the actual browser message if necessary, as shown in the following example:

try {
 window.someNonexistentFunction();
} catch (error){
 console.log(error.message);
}

This example uses the message property when displaying an error message to the user. The message property is the only one that is guaranteed to be there across Internet Explorer, Firefox, Safari, Chrome, and Opera, even though each browser adds other information. Internet Explorer adds a description property, which is always equal to the message, as well as a number property, which gives an internal error number. Firefox adds fileName, lineNumber, and stack (which contains a stack trace). Safari adds line (for the line number), sourceId (an internal error code), and sourceURL. Once again, it is best to rely only on the message property for cross-browser compatibility.

function testFinally(){
 try {
  return 2;
 } catch (error){
  return 1;
 } finally {
  return 0;
 }
}

new eval(); // throws EvalError
eval = foo; // throws EvalError

let items1 = new Array(-20);              // throws RangeError
let items2 = new Array(Number.MAX_VALUE); // throws RangeError 

let obj = x; // throws ReferenceError when x isn't declared

eval("a ++ b"); // throws SyntaxError

let o = new 10;                           // throws TypeError
console.log("name" in true);                   // throws TypeError
Function.prototype.toString.call("name"); // throws TypeError 

try {
 someFunction();
} catch (error){
 if (error instanceof TypeError){
  // handle type error
 } else if (error instanceof ReferenceError){
  // handle reference error
 } else {
  // handle all other error types
 }
}

Throwing Errors

A companion to the try-catch statement is the throw operator, which can be used to throw custom errors at any point in time. The throw operator must be used with a value but places no limitation on the type of value. All of the following lines are legal:

throw 12345;
throw "Hello world!";
throw true;
throw { name: "JavaScript" };

When the throw operator is used, code execution stops immediately and continues only if a try-catch statement catches the value that was thrown.

Browser errors can be more accurately simulated by using one of the built-in error types. Each error type's constructor accepts a single argument, which is the exact error message. Here is an example:

throw new Error("Something bad happened.");

This code throws a generic error with a custom error message. The error is handled by the browser as if it were generated by the browser itself, meaning that it is reported by the browser in the usual way and your custom error message is displayed. You can achieve the same result using the other error types, as shown in these examples:

throw new SyntaxError("I don't like your syntax."); 
throw new InternalError("I can't do that, Dave.");
throw new TypeError("What type of variable do you take me for?");
throw new RangeError("Sorry, you just don't have the range.");
throw new EvalError("That doesn't evaluate.");
throw new URIError("Uri, is that you?");
throw new ReferenceError("You didn't cite your references properly.");

The most often used error types for custom error messages are Error, RangeError, ReferenceError, and TypeError.

You can also create custom error types by inheriting from Error (discussed in Chapter 6). You should provide both a name property and a message property on your error type. Here is an example:

class CustomError extends Error {
 constructor(message) {
  super(message);
  this.name = "CustomError";
  this.message = message;
 }
}
          
throw new CustomError("My message");

Custom error types that are inherited from Error are treated just like any other error by the browser. Creating custom error types is helpful when you will be catching the errors that you throw and need to decipher them from browser-generated errors.

function process(values){
 values.sort();
         
 for (let value of values){
  if (value> 100){
   return value;
  }
 }
          
 return -1;
}

function process(values){ 
 if (!(values instanceof Array)){
  throw new Error("process(): Argument must be an array.");
 }

 values.sort();

 for (let value of values){
  if (value> 100){
   return value;
  }
 }

 return -1;
}

The error Event

Any error that is not handled by a try-catch causes the error event to fire on the window object. This event was one of the first supported by web browsers, and its format has remained intact for backwards compatibility in all major browsers. An onerror event handler doesn't create an event object in any browser. Instead, it receives three arguments: the error message, the URL on which the error occurred, and the line number. In most cases, only the error message is relevant because the URL is the same as the location of the document, and the line number could be for inline JavaScript or code in external files. The onerror event handler needs to be assigned using the DOM Level 0 technique shown here because it doesn't follow the DOM Level 2 Events standard format:

window.onerror = (message, url, line) => {
 console.log(message);
};

When any error occurs, whether browser-generated or not, the error event fires, and this event handler executes. Then, the default browser behavior takes over, displaying the error message as it would normally. You can prevent the default browser error reporting by returning false, as shown here:

window.onerror = (message, url, line) => {
 console.log(message);
 return false;
};

By returning false, this function effectively becomes a try-catch statement for the entire document, capturing all unhandled runtime errors. This event handler is the last line of defense against errors being reported by the browser and, ideally, should never have to be used. Proper usage of the try-catch statement means that no errors reach the browser level and, therefore, should never fire the error event.

Images also support an error event. Any time the URL in an image's src attribute doesn't return a recognized image format, the error event fires. This event follows the DOM format by returning an event object with the image as the target. Here is an example:

const image = new Image();

image.addEventListener("load", (event) => {
 console.log("Image loaded!");
});
image.addEventListener("error", (event) => {
 console.log("Image not loaded!");
});

image.src = "doesnotexist.gif"; // does not exist, resoure will fail to load

In this example, an alert is displayed when the image fails to load. It's important to understand that once the error event fires, the image download process is already over and will not be resumed.

Error-Handling Strategies

Error-handling strategies have traditionally been confined to the server for web applications. There's often a lot of thought that goes into errors and error handling, including logging and monitoring systems. The point of such tools is to analyze error patterns in the hopes of tracking down the root cause and understanding how many users the error affects.

It is equally important to have an error-handling strategy for the JavaScript layer of a web application. Because any JavaScript error can cause a web page to become unusable, understanding when and why errors occur is vital. Most web-application users are not technical and can easily get confused when something doesn't work as expected. They may reload the page in an attempt to fix the problem, or they may just stop trying. As the developer, you should have a good understanding of when and how the code could fail and have a system to track such issues.

Identify Where Errors Might Occur

The most important part of error handling is to first identify where errors might occur in the code. Since JavaScript is loosely typed and function arguments aren't verified, there are often errors that become apparent only when the code is executed. In general, there are three error categories to watch for:

• Type coercion errors
• Data type errors
• Communication errors

Each of these errors occurs when using specific patterns or not applying sufficient value checking.

console.log(5 == "5");  // true
console.log(5 === "5");  // false
console.log(1 == true);  // true
console.log(1 === true); // false

function concat(str1, str2, str3) {
 let result = str1 + str2;
 if (str3) { // avoid!!!
  result += str3;
 }
 return result;
}

function concat(str1, str2, str3){
 let result = str1 + str2;
 if (typeof str3 === "string") { // proper comparison
  result += str3;
 }
 return result;
}

// unsafe function, any non-string value causes an error
function getQueryString(url) {
 const pos = url.indexOf("?");
 if (pos> -1){
  return url.substring(pos +1);
 }
 return "";
} 

function getQueryString(url) {
 if (typeof url === "string") { // safer with type check
  let pos = url.indexOf("?");
  if (pos> -1) {
   return url.substring(pos +1);
  } 
 }
 return "";
} 

// unsafe function, non-array values cause an error
function reverseSort(values) {
 if (values) { // avoid!!!
  values.sort();
  values.reverse();
 }
}

// still unsafe, non-array values cause an error
function reverseSort(values) {
 if (values != null){ // avoid!!!
  values.sort();
  values.reverse();
 }
}

// still unsafe, non-array values cause an error
function reverseSort(values) {
 if (typeof values.sort === "function") { // avoid!!!
  values.sort();
  values.reverse();
 }
}

// safe, non-array values are ignored
function reverseSort(values) {
 if (values instanceof Array) { // fixed
  values.sort();
  values.reverse();
 }
}

http://www.yourdomain.com/?redir=http://www.someotherdomain.com?a=b&c=d

http://www.example.com/?redir=http%3A%2F%2Fwww.someotherdomain.com%3Fa%3Db%26c%3Dd

function addQueryStringArg(url, name, value) {
 if (url.indexOf("?") == -1){
  url += "?";
 } else {
  url += "&";
 }
  
 url += '${encodeURIComponent(name)=${encodeURIComponent(value)}';
 return url;
}

const url = "http://www.somedomain.com";
const newUrl = addQueryStringArg(url, "redir", 
                 "http://www.someotherdomain.com?a=b&c=d");
console.log(newUrl);

Distinguishing between Fatal and Nonfatal Errors

One of the most important parts of any error-handling strategy is to determine whether or not an error is fatal. One or more of the following identifies a nonfatal error:

• It won't interfere with the user's main tasks.
• It affects only a portion of the page.
• Recovery is possible.
• Repeating the action may result in success.

In essence, nonfatal errors aren't a cause for concern. For example, Gmail (https://mail.google.com) has a feature that allows users to send Hangouts messages from the interface. If, for some reason, Hangouts don't work, it's a nonfatal error because that is not the application's primary function. The primary use case for Gmail is to read and write e-mail messages, and as long as the user can do that, there is no reason to interrupt the user experience. Nonfatal errors don't require you to send an explicit message to the user. You may be able to replace the area of the page that is affected with a message indicating that the functionality isn't available, but it's not necessary to interrupt the user.

Fatal errors, on the other hand, are identified by one or more of the following:

• The application absolutely cannot continue.
• The error significantly interferes with the user's primary objective.
• Other errors will occur as a result.

It's vitally important to understand when a fatal error occurs in JavaScript so appropriate action can be taken. When a fatal error occurs, you should send a message to the users immediately to let them know that they will not be able to continue what they were doing. If the page must be reloaded for the application to work, then you should tell the user this and provide a button that automatically reloads the page.

You must also make sure that your code doesn't dictate what is and is not a fatal error. Nonfatal and fatal errors are primarily indicated by their affect on the user. Good code design means that an error in one part of the application shouldn't unnecessarily affect another part that, in reality, isn't related at all. For example, consider a personalized home page, such as Gmail (https://mail.google.com), that has multiple independent modules on the page. If each module has to be initialized using a JavaScript call, you may see code that looks something like this:

for (let mod of mods){
  mod.init(); // possible fatal error
}

On its surface, this code appears fine: the init() method is called on each module. The problem is that an error in any module's init() method will cause all modules that come after it in the array to never be initialized. If the error occurs on the first module, then none of the modules on the page will be initialized. Logically, this doesn't make sense because each module is an independent entity that isn't reliant on any other module for its functionality. It's the structure of the code that makes this type of error fatal. Fortunately, the code can be rewritten as follows to make an error in any one module nonfatal:

for (let mod of mods){
 try {
  mod.init();
 } catch (ex){
  // handle error here
 }
}

By adding a try-catch statement into the for loop, any error when a module initializes will not prevent other modules from initializing. When an error occurs in this code, it can be handled independently and in a way that doesn't interfere with the user experience.

Log Errors to the Server

A common practice in web applications is to have a centralized error log where important errors are written for tracking purposes. Database and server errors are regularly written to the log and categorized through some common API. With complex web applications, it's recommended that you also log JavaScript errors back to the server. The idea is to log the errors into the same system used for server-side errors and categorize them as having come from the front end. Using the same system allows for the same analytics to be performed on the data regardless of the error's source.

To set up a JavaScript error-logging system, you'll first need a page or entry point on the server that can handle the error data. The page need not do anything more than take data from the query string and save it to an error log. This page can then be used with code such as the following:

function logError(sev, msg) {
 let img = new Image(),
   encodedSev = encodeURIComponent(sev),
   encodedMsg = encodeURIComponent(msg);
 img.src = 'log.php?sev=${encodedSev}&msg=${encodedMsg}';
}

The logError() function accepts two arguments: a severity and the error message. The severity may be numbers or strings, depending on the system you're using. An Image object is used to send the request because of its flexibility, as described here:

• The Image object is available in all browsers, even those that don't support the XMLHttpRequest object.
• Cross-domain restrictions don't apply. Often there is one server responsible for handling error logging from multiple servers, and XMLHttpRequest would not work in that situation.
• There's less chance that an error will occur in the process of logging the error. Most Ajax communication is handled through functionality wrappers provided by JavaScript libraries. If that library's code fails, and you're trying to use it to log the error, the message may never get logged.

Whenever a try-catch statement is used, it's likely that the error should be logged. Here is an example:

for (let mod of mods){
 try {
  mod.init();
 } catch (ex){
  logError("nonfatal", 'Module init failed: ${ex.message}');
 }
}

In this code, logError() is called when a module fails to initialize. The first argument is "nonfatal", indicating the severity of the error, and the message provides contextual information plus the true JavaScript error message. Error messages that are logged to the server should provide as much contextual information as possible to help identify the exact cause of the error.

Logging Messages to a Console

All major browsers have JavaScript consoles that can be used to view JavaScript errors. All three also allow you to write directly to the JavaScript console via the console object, which has the following methods:

• error(message )—Logs an error message to the console
• info(message )—Logs an informational message to the console
• log(message )—Logs a general message to the console
• warn(message )—Logs a warning message to the console

The message display on the error console differs according to the method that was used to log the message. Error messages contain a red icon, whereas warnings contain a yellow icon. Console messages may be used, as in the following function:

function sum(num1, num2){
 console.log('Entering sum(), arguments are ${num1},${num2}');
          
 console.log("Before calculation");
 const result = num1 + num2;
 console.log("After calculation");
          
 console.log("Exiting sum()");
 return result;
}

As the sum() function is called, several messages are output to the JavaScript console to aid in debugging.

Logging messages to the JavaScript console is helpful in debugging code, but all messages should be removed when code goes to production. This can be done automatically, using a code-processing step in deployment, or manually.

Understanding the Console Runtime

The browser console is a REPL (read-eval-print loop) that is concurrent with the page's JavaScript runtime. It behaves effectively the same way as if the browser were evaluating a newly discovered <script> tag inside the DOM. Commands executed from inside the console can access globals and various APIs in the same way that page-level JavaScript can. An arbitrary amount of code can be evaluated from the console; as is the case with any other page-level code it is blocking. Modifications, objects, and callbacks will persist to the DOM and/or runtime.

The JavaScript runtime will restrict what different windows can access, and so in all major browsers you are able to select which window the JavaScript console inputs should execute in. The code you execute does not execute with elevated privilege—it is still subject to cross-origin restrictions and any other controls that are enforced by the browser.

The console runtime also has developer tool integration that offers you some contextual bonus tools to help with debugging that are not available in normal JavaScript. One of the most useful tools is the last-clicked selector, which is available in some form in all major browsers. In the Element tab inside the developer tools, when you click a node in the DOM tree, you gain a reference to the JavaScript instance of that node inside the Console tab by using $0. It behaves as a normal JavaScript instance, so reading properties such as $0.scrollWidth and invoking member methods such as $0.remove() are allowed.

Using the JavaScript Debugger

Also available to you in all major browsers is the JavaScript debugger. As part of the ECMAScript 5.1 specification, the debugger keyword will attempt to invoke any available debugging functionality. If there is no associated behavior, this statement will be silently skipped as a no-op. The statement can be used as follows:

function pauseExecution(){
 console.log("Will print before breakpoint");
 debugger;
 console.log("Will not print until breakpoint continues");
} 

When the runtime encounters the keyword, in all major browsers it will open the developer tools panel with a breakpoint set at that exact point. You will then be able to use a separate browser console that executes code at the specific lexical scope in which the breakpoint is currently stopped. Additionally, you will be able to perform standard code debugger operations (step into, step over, continue, and so on).

Browsers will also commonly allow you to set breakpoints manually (without using the debugger keyword statement) by inspecting the actual loaded JavaScript code inside the developer tools and selecting the line at which you would like to set the breakpoint. This set breakpoint will behave in the same way, but it will not persist through browser sessions.

Logging Messages to the Page

Another common way to log debugging messages is to specify an area of the page that messages are written to. This may be an element that is included all the time but only used for debugging purposes, or an element that is created only when necessary. For example, the log() function may be changed to the following:

function log(message) {
 // Lexical scope of this function will use the following instance
 // instead of window.console
 const console = document.getElementById("debuginfo");
 if (console === null){
  console = document.createElement("div");
  console.id = "debuginfo";
  console.style.background = "#dedede";
  console.style.border = "1px solid silver";
  console.style.padding = "5px";
  console.style.width = "400px";
  console.style.position = "absolute";
  console.style.right = "0px";
  console.style.top = "0px";
  document.body.appendChild(console);
 }
 console.innerHTML += '<p> ${message}</p>';
}

In this new version of log(), the code first checks to see if the debugging element already exists. If not, then a new <div> element is created and assigned stylistic information to separate it from the rest of the page. After that, the message is written into the <div> using innerHTML. The result is a small area that displays log information on the page.

Shimming Console Methods

It is burdensome to a developer to remember to use two different types of log statements—the native console.log(), and a separately defined custom log(). Because console is a global object with writable member methods, it is completely possible to overwrite its member methods with custom behavior and allow log statements sprinkled throughout the codebase to happily log to whatever you have defined.

You can define a shim as follows:

// Join all arguments into string and alert the result
console.log = function() {
 // 'arguments' does not have a join method, first convert arguments to array
 const args = Array.prototype.slice.call(arguments);
 console.log(args.join(', '));
}

Now, this will be invoked instead of the conventional log behavior. This modification will not persist a page reload so it is a useful and lightweight strategy for debugging or log interception.

Throwing Errors

As mentioned earlier, throwing errors is an excellent way to debug code. If your error messages are specific enough, just seeing the error as it's reported may be enough to determine the error's source. The key to good error messages is for them to provide exact details about the cause of the error so that additional debugging is minimal. Consider the following function:

function divide(num1, num2) {
 return num1 / num2;
}

This simple function divides two numbers but will return NaN if either of the two arguments isn't a number. Simple calculations often cause problems in web applications when they return NaN unexpectedly. In this case, you can check that the type of each argument is a number before attempting the calculation. Consider the following example:

function divide(num1, num2) {
 if (typeof num1 != "number" || typeof num2 != "number"){
  throw new Error("divide(): Both arguments must be numbers.");
 }
 return num1 / num2;
}

Here, an error is thrown if either of the two arguments isn't a number. The error message provides the name of the function and the exact cause of the error. When the browser reports this error message, it immediately gives you a place to start looking for problems and a basic summary of the issue. This is much easier than dealing with a nonspecific browser error message.

In large applications, custom errors are typically thrown using an assert() function. Such a function takes a condition that should be true and throws an error if the condition is false. The following is a very basic assert() function:

function assert(condition, message) {
 if (!condition) {
  throw new Error(message);
 }
}

The assert() function can be used in place of multiple if statements in a function and can be a good location for error logging. This function can be used as follows:

function divide(num1, num2) {
 assert(typeof num1 == "number" && typeof num2 == "number", 
     "divide(): Both arguments must be numbers.");
 return num1 / num2;
}

Using an assert() function reduces the amount of code necessary to throw custom errors and makes the code more readable compared to the previous example.

Invalid Character

The syntax of a JavaScript file must be made up of certain characters. When an invalid character is detected in a JavaScript file, IE throws the "invalid character" error. An invalid character is any character not defined as part of JavaScript syntax. For example, there is a character that looks like a minus sign but is represented by the Unicode value 8211 (u2013). This character cannot be used in place of a regular minus sign (ASCII code 45) because it's not part of JavaScript syntax. This special character is often automatically inserted into Microsoft Word documents, so you will get an illegal character error if you were to copy code written in Word to a text editor and then run it in Internet Explorer. Other browsers react similarly. Firefox throws an "illegal character" error, Safari reports a syntax error, and Opera reports a ReferenceError, because it interprets the character as an undefined identifier.

Member Not Found

As mentioned previously, all DOM objects in Internet Explorer are implemented as COM objects rather than in native JavaScript. This can result is some very strange behavior when it comes to garbage collection. The "member not found" error is the direct result of the mismatched garbage collection routines in Internet Explorer.

This error typically occurs when you're trying to assign a value to an object property after the object has already been destroyed. The object must be a COM object to get this specified error message. The best example of this occurs when you are using the event object. The Internet Explorer event object exists as a property of window and is created when the event occurs and destroyed after the last event handler has been executed. So if you were to use the event object in a closure that was to be executed later, any attempt to assign to a property of event will result in this error, as in the following example:

document.onclick = function() {
 var event = window.event;
 setTimeout(function(){
  event.returnValue = false; // member not found error
 }, 1000);
}; 

In this code, a click handler is assigned to the document. It stores a reference to window.event in a local variable named event. This event variable is then referenced in a closure that is passed into setTimeout(). When the onclick event handler is exited, the event object is destroyed, so the reference in the closure is to an object whose members no longer exist. Assigning a value to returnValue causes the "member not found" error because you cannot write to a COM object that has already destroyed its members.

Unknown Runtime Error

An unknown runtime error occurs when HTML is assigned using the innerHTML or outerHTML property in one of the following ways: if a block element is being inserted into an inline element or you're accessing either property on any part of a table (<table>, <tbody>, and so on). For example, a <p> tag cannot technically contain a block-level element such as a <div>, so the following code will cause an unknown runtime error:

p.innerHTML = "<div>Hi</div>"; // where p contains a <p> element

Other browsers attempt to error-correct when block elements are inserted in invalid places so that no error occurs, but Internet Explorer is much stricter in this regard.

Syntax Error

Often when Internet Explorer reports a syntax error, the cause is immediately apparent. You can usually trace back the error to a missing semicolon or an errant closing brace. However, there is another instance where a syntax error occurs that may not be immediately apparent.

If you are referencing an external JavaScript file that for some reason returns non-JavaScript code, Internet Explorer throws a syntax error. For example, if you set the src attribute of a <script> to point to an HTML file, a syntax error occurs. The syntax error is typically reported as the first line and first character of a script. Opera and Safari report a syntax error as well, but they will also report the referenced file that caused the problem. Internet Explorer gives no such information, so you need to double-check every externally referenced JavaScript file. Firefox simply ignores any parsing errors in a non-JavaScript file that's included as if it were JavaScript.

This type of error typically occurs when JavaScript is being dynamically generated by a server-side component. Many server-side languages automatically insert HTML into the output if a runtime error occurs, and such output clearly breaks JavaScript syntax. If you're having trouble tracking down a syntax error, double-check each external JavaScript file to be sure that it doesn't contain HTML inserted by the server because of an error.

The System Cannot Locate the Resource Specified

Perhaps one of the least useful error messages is "The system cannot locate the resource specified." This error occurs when JavaScript is used to request a resource by URL and the URL is longer than Internet Explorer's maximum URL length of 2083 characters. This URL length limit applies not just to JavaScript but also to Internet Explorer in general. (Other browsers do not limit URL length so tightly.) There is also a URL path limit of 2048 characters. The following example causes this error:

function createLongUrl(url) {
 var s = "?";
 for (var i = 0, len = 2500; i < len; i++){
  s += "a";
 }
  
 return url + s;
}
          
var x = new XMLHttpRequest();
x.open("get", createLongUrl("http://www.somedomain.com/"), true);
x.send(null);

In this code, the XMLHttpRequest object attempts to make a request to a URL that exceeds the maximum URL limit. The error occurs when open() is called. One workaround for this type of error is to shorten the query string necessary for the request to succeed, either by decreasing the size of the named query string arguments or by eliminating unnecessary data. Another workaround is to change the request to a POST and send the data as the request body instead of in the query string.