DEV Community: Adam Yeats

JavaScript Errors: An Exceptional History - Part II

Adam Yeats — Tue, 26 Nov 2019 15:05:58 +0000

Hello again! Welcome to the finalé of a two-part series of posts on errors in JavaScript.

Last time, we took a look into the history of errors in JavaScript — how JavaScript shipped without runtime exceptions, how error handling mechanisms were later added both to the fledgeling web browsers of the day and to the ECMAScript spec, and how they future efforts to standardise these features would be connected to the politics of the browser wars of the late 90's and 2000's.

This time, we'll focus a little more on the state of affairs in JavaScript today. We'll look at the different ways you can handle errors in your app today, the various idiosyncrasies they have, and how you can use our JavaScript client library to report errors from your app to our dashboard.

Let's do it!

Handling Errors Today

After the last post, you may be forgiven for thinking that handling errors gracefully in JavaScript might be a bit of a nightmare. Luckily, it's not so daunting a prospect as it might seem, but there are quite a few different ways to handle errors with varying levels of scope and different use cases.

`window.onerror` Handler

The window.onerror handler exists today in all modern web browsers as a means to catch uncaught exceptions from the current window. Any thrown error that is not otherwise handled in a try/catch block will be passed to the handler as the first argument to that function. The current window refers to the current global context, so it's important to note that <iframe>s and Web Workers (for example) will have their own window context.

When we use a window in the following examples, we're referring to the global window context of the browser.

By assigning a function to window.onerror, we can write custom logic to handle any uncaught exceptions that are thrown during the lifecycle of our application:

// NOTE: using typescript syntax here in order to show what types the arguments are

function onError(msg: string | Event, source?: string, lineno?: number, colno?: number, error?: Error) {
// error handling code here!
}

window.onerror = onError;

You might notice that some of these arguments are marked as optional. This is because, as you might guess, browsers disagree on the number of arguments passed to the onError handler. Browsers as recent as Safari 9, for example, do not pass an Error object as its fifth argument. Internet Explorer 9 passes neither the colno or error arguments. Because of this inconsistency, care needs to be taken when writing an onError handler that works in older browsers.

However, thanks to the existence of the Error object in most modern browsers, you can normally rely on that 5th argument to be present, which will include some useful information that might come in handy when debugging, such as the current stack trace (error.stack).

As this handler tends to be a little noisy (thanks, browser extensions...), the AppSignal JavaScript library doesn't automatically catch exceptions passed to the window.onerror handler. Instead, we have packaged this functionality in an optional plugin — the @appsignal/plugin-window-events package on npm.

As a convenience, once the onError handler is called, most browsers will call console.error behind the scenes to display the Error object (often including its stacktrace) in the console.

The Document Object Model Level 2 specification introduced the EventTarget interface to provide a generic way to bind event listeners to an Element (or other objects like Document and Window) that worked cross-browser, but also added features like the ability to have multiple handlers bound to an event. This means that many of the older event handlers, such as our friend onError, received a modern facelift.

window.addEventListener("error", function(event) {
  // error handling code here!
});

In this example, you can see that the event of type ErrorEvent is passed as the single argument to your callback. The event object contains both the information about the error but also the event itself, but again, older browsers differ in the information they provide in the event.

`try`/`catch` Operator

For synchronous code, the humble try/catch operator remains the most common way to handle exceptions. As we discussed in the previous post, try/catch exception handling allows you to try executing a block of code that may throw errors at runtime; if it does, the exception is then caught by the catch block, allowing us to control what happens and what state our app is left in.

While it's certainly true that JavaScript still allows you to throw any value as an exception, community convention has filled the gap where the ECMAScript specification leaves ambiguity; it is more commonplace to receive Error objects as the argument to the catch block nowadays, and good library implementors will generally throw Error objects for you to handle.

try {
  throw new Error("I'm broken");
  // generates an exception
} catch (e) {
  // statements to handle any exceptions
} finally {
  // clean up
}

In the catch block, you should add any code that allows you to put your app back into a defined state.

React's documentation for their Error Boundaries feature explains the problem well from a UI perspective, and the same is also true for exception handling as a whole:

For example, in a product like Messenger leaving the broken UI visible could lead to somebody sending a message to the wrong person. Similarly, it is worse for a payments app to display the wrong amount than to render nothing.

It's also a good idea to log your exception somewhere — failing silently is rarely useful, your aim here is to surface the exception as best as you can to debug problems before they become a problem for the user.

In your code, the catch block is where you would want to include your call to appsignal.sendError() if you're using our JavaScript library. Here, you can pass the Error object as an argument and have it appear in your Errors dashboard.

The finally block tends to not be as useful in JavaScript as it is in other languages. In the finally block, normally should try to clean-up any resources created before the exception was thrown, however as JavaScript is a garbage-collected language and resources are allocated and de-allocated dynamically, we often don't have to think about this much. There are times where this can be useful, however, such as for closing open connections to remote services regardless of whether the request to it was successful or not.

Promises and Async JavaScript

Admittedly, in our last post, we might have seemed a little negative about the design of JavaScript as a language. While it's almost certainly true that a lot of mistakes were made — and thanks to the ever-present need for backwards compatibility, many of them still exist today — arguably, there has been a lot of ground covered since then to make amends, and many aspects of the original design of JavaScript still hold up well today.

One of those areas that JavaScript is great at is asynchronous programming. JavaScript is an event-driven language, which is, in its simplest terms, the means to allow code to be executed by listening for events that can be triggered based on user interaction, or even messages from other programs. This is a great fit for a language like JavaScript that is mostly found embedded in a graphical environment, where you might feasibly want to execute code based on mouse clicks, or key presses.

Thanks to JavaScript's Event Loop (a concept we'll cover in full in a later edition of JavaScript Sorcery) and recent developments in the language, JavaScript lets you define points in your program where the flow of execution can be returned to the program in lieu of a value, allowing the rest of your program to run and the UI to update, and the value to the latter be filled later. We call these values Promises.

Promises themselves can contain exceptions, which when they are thrown, cause the Promise to become rejected. Once rejected, a Promise can execute a user-defined callback that we chain to it using .catch.

// You can catch errors asynchronously by listening to Promises...
asyncActionThatReturnsAPromise().catch(error => appsignal.sendError(error));

Errors can also be caught in the onRejected handler, a second parameter to .then that takes a function.

asyncActionThatReturnsAPromise().then(onFulfilled, onRejected):

The first argument to the .catch callback will normally be an Error object, but just like the try/ catch statements above, there is no explicit rule about what kind of value a Promise can be rejected with and thus passed to the .catch callback. It could technically be any value. We recommend that, when writing your own Promises, you do yourself and any future developers using your code the courtesy to reject Promises with Error objects.

Any Promises that become rejected that don't have a callback bound to the .catch handler will instead fire a callback on the window object called onunhandledrejection.

window.onunhandledrejection = function(e) {
  // error handling code here!
}

Recently, the ECMAScript standard was amended to add the async/await keywords. With these keywords, we can write async code that looks like synchronous code by using the await keyword within an async function to denote to the program that it should pause execution of the async function and wait for a value that a Promise is fulfilled with.

As we can use async/ await and async functions to write code that looks like it's synchronous even though it's not, then it's sensible to expect that we can also use the try/catch statement to handle exceptions within them, and in fact, we can!

// ...or by using async/await
async function() {
  try {
    const result = await asyncActionThatReturnsAPromise();
  } catch (error) {
    appsignal.sendError(error);
    // handle the error
  }
}

C'est tout!

That's all we have for this week!

Don't forget: our JavaScript integration was released recently and we'd love for you to give it a try in your front-end applications and tell us what you think.

If you liked this post, subscribe to our new JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

JavaScript Errors: An Exceptional History

Adam Yeats — Fri, 18 Oct 2019 15:10:23 +0000

It's a historic week here at AppSignal! 🎉 This week we released the first version of our new and improved JavaScript error monitoring. Now you can have your front end code, Ruby or Elixir back end code, your hosts, performance, everything monitored in one interface.

To celebrate the launch, in a two-part series of posts, we'll be taking a look at the history of Errors in JavaScript, including how to handle them in your code today. In this part, join us as we go through the origins and turbulent years of growth of JavaScript and see it grow into the language it is today.

A Comedy of Errors

In accordance with Murphy's Law, arguably ticket #1 on the backlog of the great Jira board of the universe, runtime errors have existed as a concept since the very first version of JavaScript, shipped as part of Netscape Navigator 2.0 in 1995, and later as part of the second iteration of Internet Explorer.

Here in 2019, it's difficult to conceive of a primordial version of JavaScript. Famously prototyped in 10 days, and publicly released mere months later, the early history of JavaScript exists as a flawed, but nonetheless impressive, monument to compromise and short-term corporate thinking; plans to implement Scheme as the embedded scripting language in Netscape Navigator gave way to desires to include a "glue language" to compliment Java, producing a hybrid of syntax vaguely resembling Java but with ideas cribbed from dynamically typed languages like Scheme, HyperTalk and Self in order to differentiate itself from the more "serious" and statically typed Java.

One Point Uh-Oh

JavaScript 1.0 shipped without some common language features. For instance, support for a list-like data structure (the Array object was added in version 1.1). Object and array literals ([] and {}) would not arrive until JavaScript 1.2. Some features changed rapidly — JavaScript 1.2 changed the == and != operators to make them no longer coerce types if the compared values were not of the same type. This would later be reversed with version 1.3 with the advent of the ECMA standardization, and the === and !== operators would fill the gap.

Perhaps most pertinent to the theme of this post, however, JavaScript shipped without the ability to handle runtime errors. If your script produced a runtime error, at the time, there was no mechanism to recover from this. A runtime error would "crash" the page, and present the user with an ugly, cryptic error message and no other option than to reload and hope that, fingers crossed, the script would evaluate correctly this time. Those of us using the web in those days don't get the warm-and-fuzzies when we remember the dreaded un-closable "Script error" dialog, but luckily those days are far behind us.

The wake of these, and many other, decisions of those ten days in May 1995 has stretched unusually far into the future. It can be argued that the perception of JavaScript as a folly, a mere toy language for those not competent enough to embrace "real" languages, is birthed from these early design flaws and Netscape's own marketing attempts to position JavaScript as a sidecar to Java, a reputation that has been hard for JavaScript to shake as its adoption and ubiquity grows.

Ultimately, however, extensions were made to the JavaScript language to address many of these initial hurdles, leading to the eventual standardization of JavaScript as ECMAScript in 1997, the formation of TC39, and the beginning of the tumultuous journey to the JavaScript of today.

An Exceptional History

The first version of the ECMA-262 standardization of JavaScript included a section on errors short enough to be almost memorizable. It talks very little about runtime errors, only hinting at "catchable [errors] in future versions". It would take until the 3rd Edition of ECMA-262 (colloquially known as ES3) for proper exception handling semantics to be ratified as part of the ECMAScript specification.

In the meantime, it would be Netscape who would take the initial steps and add two of the core pillars of JavaScript error handling.

`window.onerror`

Version 1.1 of JavaScript (shipped with Netscape Navigator 3.0), would be the first to have a mechanism for error handling of any kind, in the form of the window.onerror event. JavaScript was designed as an event-driven language from the very beginning.

In the Netscape Navigator 3.0 documentation, the window.onerror event is originally defined as firing when "the loading of a document or image causes an error".

In Navigator 3.0, handling an error would look like this:

function onError(msg, url, lineno) {
  // error handling code here!
}

window.onerror = onError

This enabled JavaScript developers of the time to create something resembling a trace from the arguments provided to the event handler but did not offer any solutions with regards from recovering from an error.

`try`/`catch`

Basic exception handling constructs like try/catch and throw were not a part of language until JavaScript 1.4, a version of JavaScript that was only used for Netscape LiveWire, a server-side JavaScript implementation released in 1999, predating Node.js by a decade. They do not appear in the ECMAScript specification until version 3. This can be considered the second "true" version of the ECMAScript standard (ECMAScript 2 contained only editorial changes).

Although exception handling as a concept predates it by many years in both software and hardware, try/catch exception handling was a concept first introduced in software in C++ and later extended with the finally block in Java. A program can "try" executing a block of code that may throw an exception, and interrupt the normal flow of execution of our program and execute code defined in the catch block if it does.

A throw statement will pass the value to its right-hand side to the first argument of the catch block. This could be any value; a common pattern in JavaScript was to throw a string and handle the error conditionally. Over time, conventions and best practices evolved, and it would become more common to throw an Error object instead. No further statements beyond the throw statement will execute. Instead, the code inside the catch block will execute. This allows a developer to write logic to recover from runtime errors or log them somewhere for debugging at a later stage.

The finally block always executes, regardless of whether an exception was thrown or caught. If no catch block exists in the call stack when an exception is thrown, the script will simply terminate.

try {
  throw "I'm broken" // generates an exception
}
catch (e) {
  // statements to handle any exceptions
}
finally {
  // clean up
}

This change to JavaScript syntax would modify the semantics of the window.onerror handler somewhat. As many errors could now be handled at runtime, the window.onerror would begin to evolve into a funnel for unhandled exceptions.

The `Error` object

Another crucial ingredient of the JavaScript error handling picture is the Error object.

The Error page on MDN is a fascinating read in itself. The Error object is a compendium of inconsistency — a child of the badlands of the late 90's and oughts, an era in web development where new JavaScript features, rather than introduced and standardised on a yearly basis in a co-operative effort between vendors and developers like they are today, were created in a standoff of sorts between two major browser vendors vying for dominance of an industry in its infancy.

The roots of the Error object can be traced back to JScript 5, Microsoft's own reverse-engineered implementation of the ECMAScript standard and included in Internet Explorer. This marked the first time that instances of an Error object could be thrown when runtime errors occurred, and could also be inherited from to create custom exceptions.

function broken() {
  if (true) {
    throw new Error("I am an error")
  }
}

try {
  broken()
} catch (e) {
  // e.name = "Error"
  // e.message = "I am an error"
}

Early documentation from Netscape Navigator exists that implies the creation of your own custom exception object was expected, however Microsoft was somewhat ahead of the curve here with a more detailed exception object that could be thrown in place of a primitive value like a string.

A quirk of the early Microsoft Error object compared to the ECMA-standardised version is that the alternative arguments you could provide:

new Error(num: number, description?: string)

The first argument was intended to be a value which, when combined with the & (bitwise And) operator to combine the number property with the hexadecimal number 0xFFFF, would return the actual error code.

The existence of the Error object was later given legitimacy as part of the ECMAScript 3 specification, however, it's implementations remain inconstant across browsers to this day. The Error object as specified in ECMA-262 has two intrinsic properties: the description of the error (message, description in earlier Microsoft implementations) and the name of the error (name).

However, browser vendors have since added their own extensions to the Error object, the most notable of which being the stack property, returning a string representation of which functions were called leading up to the exception, in what order, from which line and file, and with what arguments. Although not part of the ECMAScript standard, almost all modern browsers include an Error object with a stack property. Older browsers, such as IE9, do not include this functionality.

Backtracing to today

This brings us back to today. The AppSignal JavaScript library depends heavily on the stack property's presence to provide a backtrace in the UI — if it's not present, then there's no backtrace that we can display.

In some cases (namely inside the plugin for window events), we attempt to construct a partial stack trace if none is present from the best information available at the time, but in some situations, no stack trace will be available at all. Luckily for all of us, the percentage of browsers in use today that do not support the Error object's stack property is relatively marginal.

That’s it for now!

Next time, we'll look at how errors are handled in JavaScript today, including methods to handle asynchronous code and how to best use the AppSignal JavaScript library to track them.

We're super excited to have our JavaScript error tracking out in the wild, so please give it a try and tell us what you think.

If you liked this post, subscribe to our new JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

JavaScript Iterators and Iterables

Adam Yeats — Wed, 17 Jul 2019 11:11:21 +0000

Welcome to our first in-depth post on JavaScript! Here at AppSignal, we're gearing up to launch our all-new front-end monitoring solution, something we're very excited about and hope you will be, too.

Over the last few years, I've watched JavaScript evolve from somewhat of an oddity—an admittedly imperfect, but often misunderstood, scripting language for the browser—to a powerful and expressive language in its own right, deployable in multiple environments, and almost ubiquitous in today's computing landscape.

The aim of this corner of AppSignal.com is to explore this language in greater detail and uncover The Good Parts™ that make JavaScript awesome. Much like our sister blogs, Ruby Magic and Elixir Alchemy, we'll deep-dive into language features, patterns and frameworks, and share some other JavaScript insights along the way, too.

Let's get to it! But first, let's talk about Ruby.

On Linked Lists and Rubyists

In a previous edition of Ruby Magic, Jeff explored Ruby's Enumerator objects and Enumerable module. This is described by Jeff like this:

Enumeration refers to traversing over objects. In Ruby, we call an object enumerable when it describes a set of items and a method to loop over each of them.

Alright, sounds useful! I can already see plenty of reasons why you'd want this. In the aforementioned post, Jeff uses Enumerable to implement a Linked List — a common, almost evergreen data structure type that is a collection of data elements, in which each element points to the next. Each element in the list has two values, named the head and the tail. The head holds the element’s value, and the tail is a link to the rest of the list.

By ensuring that the linked list responds to the #each method, and by including the Enumerable module, it's possible to implement this data structure in Ruby without writing a whole mess of code. This got me thinking - I wonder if JavaScript can do something like that?

The answer: yes, it can! But, this wouldn't be a JavaScript blog post unless I told you that, of course, things are a little different here. Today, we're going to introduce you to JavaScript's close relative of Ruby's Enumerable class, the Iterable, and how we can leverage it to write a LinkedList class of our own.

Some of you may have never had to have implemented a Linked List before. No doubt, many of you have had to have implemented one as part of a job interview. Perhaps you, like the React team, are already using them to do non-trivial things in your codebase. The example we'll be implementing today is almost an exact port of Jeff's Ruby LinkedList class to JavaScript, which I really like due to the simplicity of the implementation. It is, perhaps, a little easier to grasp what's going on here than it would otherwise be with a "full-fat" implementation.

It doesn't catch all the edge cases, or provide a number of class methods that you might expect, but should help illustrate the idea. Consider yourself warned: you will be sent to programming hell if I catch you using this code in production, and there, no amount of random key combinations will help you exit Vim.

Okay, let's begin.

So, what's an iterator?

An iterable in JavaScript is an object that defines custom iteration behaviour via a method on itself or any of the objects in its prototype chain. You're probably already quite familiar with some of the built-in JavaScript types that are iterables, chiefly Array, Map, Set and String. In common programming parlance, we say that these types can be "looped over"; given a construct like a for loop, we can extract each value in order from the iterable and do something with it.

JavaScript provides the for...of loop for iterating over a generic iterable:

for (let value of iterable) { 
  console.log(value); 
}

You can also destructure an iterable to get a subset of its values as named variables. In the following example, a === 'a' and b === 'b':

const [a, b] = new Set(['a', 'b', 'c']);

Iterables can even be spread into an array literal, transforming your iterable into a linear array and allowing you to call array methods like .map() or .filter() on the returned value:

[...iterable].map(el => console.log(el));

So what makes an object iterable? Here's where things start to get a little more advanced.

`@@iterator` - The Invisible Property

In order to become an iterable, a special function must be implemented on the object itself - @@iterator. Now, to many of you out there, you would be forgiven to have been blissfully unaware that this property ever existed. It can't be accessed by calling iterable.@@iterator. It doesn't show up in a for loop or when calling Object.keys on an iterable. Often, console.log won't even reveal this property. So, where is it?

Unlike other programming languages, JavaScript doesn't (yet) have the concept of private methods or private fields on an object, but we can make a property of an object "pseudo-private" by referencing it using a special JavaScript type called a Symbol. The @@iterator property is implemented in this way: the value of the @@iterator property can only be referenced using a Symbol key that is defined as a constant on the Symbol type itself: Symbol.iterator.

Accessing it works like this:

class LinkedList {
  // ...
  [Symbol.iterator]() {}
}

// ...or using an object literal
const LinkedList = {};
LinkedList[Symbol.iterator] = function () {};

On a given class or object, where the key is Symbol.iterator, the value must be a function. In a classic, synchronous implementation of an iterator, this function returns an object (called an iterable) that implements a function called next() as a property. Let's expand a little further on our example to see what this looks like:

class LinkedList {
  // ...
  [Symbol.iterator]() {
    return {
      next() {
        return {
          value: "a value",
          done: false
        }
      }
    }
  }
}

Holy nested statements! We've managed to erect a small pyramid in our shiny new codebase, but we have successfully implemented an iterator that returns an iterable. The iterable itself returns an object with two properties: value and done. Unsurprisingly, value is the current value of the iterator, and done is a boolean value to communicate to the iterator if the sequence of values has ended. If done === true, then the value property can be emitted.

Now we know a little more about how iterators and iterables work, let's see how we can apply this knowledge to build a LinkedList.

Building the `LinkedList`

Let's start out by just porting Jeff's Ruby class into JavaScript, sans the #each method used to create an Enumerable:

class LinkedList {
  constructor(head = null, ...rest) {
    this.head = head;

    if (rest[0] instanceof LinkedList) {
      this.tail = rest[0];
    }
    // roughly equivalent to `rest.any?` in ruby
    else if (rest.some(el => el)) {
      this.tail = new LinkedList(...rest);
    }
    else {
      this.tail = null;
    }
  }

  add(item) {
    return new LinkedList(item, this);
  }
}

So far, so good. Using the above example, we can already create a new LinkedList, and add new items to the head of the LinkedList, using the rest and spread operator (...) to create the tail. As the first argument to the constructor, we allow anyone using our LinkedList class to pass a head as the top of the linked list, and the rest operator in the constructor is able to convert any remaining arguments that are not head, and convert them to an array. The else if statement creates a new LinkedList from this array, and continues to do so until the last item in rest belongs to the head of a LinkedList.

Now, we'll need to implement the logic to retrieve the items from the LinkedList, but I can already see a problem. If we implement an iterator, and the subsequent iterable, using the technique outlined above, then we're already deviating from Jeff's initial design quite considerably. There's a lot more code to write, and we'll need to maintain state somehow, as we need to tell the iterable that our sequence is finished by setting done to true. It's certainly possible, but I think we can come up with something more elegant.

Enter the Generator function.

Generator functions

The value we set as Symbol.iterator can also be a generator, a new type of function that was introduced with ECMAScript 2015. The easiest way to think of a generator function is a function that you can exit and return to at will, optionally returning a value with the yield keyword. Using the power of closures, we can maintain the state of the function across multiple yields and re-entries. Importantly, generator functions have the same interface as an iterable, meaning values can be retrieved in the same manner as if we had implemented the iterable ourselves.

Let's implement an iterator to get all of the values from our LinkedList using a generator function:

class LinkedList {
  // ...implementation

  *[Symbol.iterator]() {
    yield this.head;
    let next = this.tail;

    while (next !== null) {
      yield next.head;
      next = next.tail;
    }
  }
}

The Full Implementation

So, when all is said and done, this is what we end up with:

class LinkedList {
  constructor(head = null, ...rest) {
    this.head = head;

    if (rest[0] instanceof LinkedList) {
      this.tail = rest[0];
    }
    // roughly equivalent to `rest.any?` in ruby
    else if (rest.some(el => el)) {
      this.tail = new LinkedList(...rest);
    }
    else {
      this.tail = null;
    }
  }

  add(item) {
    return new LinkedList(item, this);
  }

  *[Symbol.iterator]() {
    yield this.head;
    let next = this.tail;

    while (next !== null) {
      yield next.head;
      next = next.tail;
    }
  }
}

We can then use our new LinkedList class like so:

const ll = new LinkedList(0, 1, 1, 2, 3, 5, 8, 13);

for (let value of ll) { 
  console.log(value); // output: 0, 1, 1, 2, 3, 5, 8, 13
}

const [a, b] = ll; // a = 0, b = 1

[...ll].map((num) => console.log(num)); // output: 0, 1, 1, 2, 3, 5, 8, 13

And that's it!

The first time the function is run, we yield the current head. Then, as long as there is a tail to read from, we yield the head of the list item on the tail. Once we've done that, the iterator is implicitly done. In seven lines of code, we've implemented our iterator. Awesome!

Let us know what you think about this blog, or what JavaScript wonders you'd like us to write about on Twitter @AppSignal