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 🙏

© 2025 – Pkg Stats / Ryan Hefner

tinyerror

v0.1.2

Published

Easy custom errors in browsers, Node, and Applitude

Downloads

14

Readme

Tinyerror Build Status

Easy custom errors in browsers, Node, and Applitude

Here's a simple example:

var e = error('Error Name', 'Error message');

Once you have your custom error object, you can do whatever you like with it. Suggestions:

  • Pass it into a promise rejection
  • Log it
  • Throw it (use with caution, don't throw in asynchronous code)

That's not all it can do, of course. Here's the full call signature:

var e = error(name, message, code, proto);

The code parameter lets you assign an error code to an error, and store it for later reference on the error.errors object.

var e = error('Not Found', 'Where did you last see it?', '404');

You can get errors by code by calling the error.code() method:

var e = error.code('404'); // Get the cached 404 error.

Error codes can be any valid string, as long as they're unique. This snippet will retrieve a cached error with the code, "my custom error code".

var e = error.code('my custom error code');

If you define an error code that already exists, the most recent definition wins (the existing one gets overridden).

The proto parameter lets you pass in a custom error prototype. For example, to inherit from TypeError:

var e = error('TypeError', 'Expected type: string',
  'TypeError.StringExpected', new TypeError());

A globally shared pool of standard errors is great, but what if you have domain-specific errors you want to limit to your own module? No problem, just create a new instance of the error object. For instance, a media player might need some playback errors:

var mediaError = error.createInstance(),
  e = mediaError('PlayError', 'Can\'t play media file.', 'PlayError');

Tips

  • Don't throw from async functions. Instead, reject a promise with it, or pass it into a callback. Note that none of these methods will throw an error for you automatically, so they're safe to use anywhere.

  • Too many error types is just as bad as too few. Keep it in check.

  • You can store and pre-load application-level custom error types from json. Just set or extend the error.errors object after you load the error library.

Credit