npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

fault-tolerance

v1.3.1

Published

Process errors and normalize the output

Downloads

24

Readme

pipeline status

This project isn't dead; it is feature complete and stable.

fault-tolerance

Process and normalize errors

This module offers a simple Fault class that will normalize the output of an error. Additional context can be associated and included in the toString() making analyzing what went wrong easier.

Installation

Available as an NPM Package $ npm install fault-tolerance

Details

Fault.id Get a unique identifier for the error

Fault.log Get the formatted output

Fault.toObject() Get an object representing the formatted output

Fault.toJson() Get a JSON formatted version of the output. The Stacktrack will be split into an array.

constructor(data, context, preProcess) Create a new Fault using the given data and context. Aditionally you an pre-process the context before it is written to the Fault. See examples below

Example

See on RunKit

The Fault class extends Error which means at the most basic use-case is throw new Fault('Something bad happened');

More often than not you need additional context in an error.

let context = {
  prop1: 'value',
  prop2: false
}

throw new Fault('Nothing to see here', context);

the output from that would be

Error: Nothing to see here
  at ......
  at ......
  at ......
id: k06varft.9y6
metadata:
{
  "prop1": "value",
  "prop2": false
}

There are a few intricacies of the data and context params. If the data is a string then that will become the message of the error. However, if the data is an object or array it will be merged into the context. If the data object has a message property then it will be used as the message for the error.

const data = { message: 'test', prop: 2 };
const context = { prop: 1 };
let error = new Fault(data, context);

Output:

Error: test
  at ......
  at ......
  at ......
id: k06varft.9y6
metadata:
{
  "prop2": 1,
  "message": "test",
  "prop1": 2
}

A real-world usecase of this is when you are using some 3rd party API and you want some request context in the thrown error. Note that even though you are throwing a new error the original stack trace is entact.

function checkWeather(location){
  try {
    let result = weatherAPI.getForecast(location);
  }
  catch(e) {
    e = new Fault(e, {location:location});
    logger.log(e.log);
    throw e;
  }
}

Or if you just wanted to cleanly include additional context in any error you throw

function checkpoint(droids:[]){
  try{
    droids.forEach(d => {
      if(d.isWanted) {
        if(jediIsPresent) {
          throw new Error('These are not the droids you are looking for');
        }
        detain(d);
      }
    })
  }
  catch(e) {
    // a Fault will preserve the original stacktrace
    throw new Fault(e, {droids: droids});
  }
}

The output from that would look like:

Error: These are not the droids you are looking for
  at ......
  at ......
  at ......
id: k06varft.9y6
metadata:
{
  "droids": [
    {
      "name": "R2D2",
      "isWanted": true
    },
    {
      "name": "C3PO",
      "isWanted": true
    }
  ]
}

Sometimes you will need to make sure sensitive information isn't written to the logs. Add a pre-Processor to the constructor to ensure the context is how you want it.

function redactUserInformation(context){
  delete context.address;
  delete context.phone;
  delete context.emailAddress;
  return context;
}

// user:{id, address, phone, emailAddress }
function processClaim(user){
  try{
    claims.proccess(user);
  }
  catch(e){
    throw new Fault(e, user, redactUserInformation);
  }
}
Error: Error while processing claim
  at ......
  at ......
  at ......
id: k06varft.9y6
metadata:
{
  "id": "17a876df0b"
}