JSPM

  • ESM via JSPM
  • ES Module Entrypoint
  • Export Map
  • Keywords
  • License
  • Repository URL
  • TypeScript Types
  • README
  • Created
  • Published
  • Downloads 4
  • Score
    100M100P100Q77143F
  • License MIT

A better way to handle errors

Package Exports

  • betterr
  • betterr/dist/index.js
  • betterr/dist/index.mjs

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (betterr) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

betterr

A better way to handle errors

build status coverage

Advantages

Unlike with try...catch or promises:

  • Both data and errors are declared with const, available at the top level, and non-nullable (once the other is handled)
  • Errors are always Error objects

Installation

$ npm install betterr

Usage

  1. Wrap any code that may throw
import { betterr } from 'betterr'; // const { betterr } = require('betterr');

const [user, err] = await betterr(() => getUserWithId(1));
// user: User | null, err: Error | null
  1. Now either
  • Avoid handling the error, and use optional chaining

    const maybeName = user?.name; // maybeName: string | undefined
  • Handle the error (interrupting the control flow), after which optional chaining is not needed

    if (err) return; // user: User (after error handled)
    const name = user.name; // name: string

Explanation

betterr / betterSync execute a callback and return a tuple with data (callback return value) and err (error during execution), one of which will be null depending on the success of the callback.

  • betterr can be used with both asynchronous and synchronous callbacks.

  • betterrSync can only be used with synchronous callbacks, but avoids wrapping the data in a promise so that await is not necessary.

TypeScript

Both betterr and betterrSync are generic.

  • The callback return type must be assignable to the first generic parameter (for data). It defaults to the callback return type.
  • The second generic parameter (for err) must extend the Error object. It defaults to Error.
/**
 * const betterrSync: <TData, TError extends Error = Error>
 * (callback: () => TData) => [TData, null] | [null, TError]
 */

const [user, err] = betterrSync<User, RangeError>(() => ({ id: 1 }));
// data: User | null, err: RangeError | null