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

berror

v1.1.1

Published

Simple error handling

Downloads

1,108

Readme

npm type definitions npm GitHub code size in bytes Maintenance

BError - Better Error Handling

Inspired by VError and written in TypeScript. Compatible with deno. Zero dependencies.

A BError is just like a regular Error with three added benefits:

Chain of causes

When you create a BError you can provide it with the error that caused it. It doesn't need to be a BError. Any Error will work:

try {
  throw new Error("Something went wrong")
} catch (e) {
  throw new BError("Oops", e)
}
// will create an error with the message: `Oops: Something went wrong`

Metadata

You can add some metadata to your errors to help with debugging:

const path = "/test"
try {
  tryToOpenPath(path)
} catch (e) {
  throw new BError("Could not open path", e, {path})
}
// will create an error with the message:
// `Could not open path: permission denied {path: "/test"}`

The metadata is kept in the chain, the final error will contain all the metadata of the errors that caused it. If two errors send the same metadata property, the last one will override the first one.

If you want to send metadata but you don't have an error that you just caught you can pass undefined or null to the constructor: new BError("Oops", undefined, {foo: 42})

Logging

BError comes with a log function that makes it easy and short to log the error.

  // will log the error using console.error()
  new BError("Something went wrong").log()

Using a custom logger

BError is meant to be extended to integrate your own logger. Just extend the BError class and override the log function to do whatever you want.

Example with winston:

import {BError} from "berror"
import {createLogger, transports} from 'winston'

const logger = createLogger({
  level: 'debug',
  transports: [
    new transports.Console()
  ]
})
  

export class MyError extends BError {
  public log(level: string) {
    if (level === "error") {
      logger.error(this.message, this.metadata)
    } else {
      logger.info(this.message, this.metadata)
    }
  }
}