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

@qest/error-utils

v1.0.1

Published

-

Downloads

1,583

Readme

Error utils

Throw normalized errors for better error handling and understanding what happend in our code.

Package include ancestor of all your errors and implementation of HTTP errors for simply use. In the package you also find swagger documentation for HTTP errors which can be used with @qest/swagger-utils package.

Instalation

Install package to our dependencies from NPM.

yarn add @qest/error-utils

or

npm install @qest/error-utils

Usage

For normalization of errors is good to have one ancestor for all errors which you throw in code. Also there is better to have more types of concrete errors for understanding what happend on first look.

Define own errors

import { BaseError } from "@qest/error-utils";

export class SomeError extends BaseError {}

enum EnumOfErrorTypes {
    OneType,
    SecondType,
};
export class ComplexError extends BaseError<EnumOfErrorTypes> {}

Use it in code

In this example you can see usage of previously defined errors. You must define type and message in error description. You can also pass some data to payload, which is usefull for debugging what happend.

try {
    // ... do something ...
    if(isBad){
        throw new SomeError({
            type: 'MY_ERROR_TYPE';
            message: 'some bad was happend';
        });
    }
    
    const data = { foo: 'bar' };
    // ... other code with data manipulating ...   
    if(data.foo !== 'bar') {
       throw new ComplexError({
            type: EnumOfErrorTypes.SecondType,
            message: 'Some bad was happend',
            payload: data,         
       });
    }
    
} catch (e) {
    console.error(e);
}

Error descriptor object

All base error accept IBaseErrorDescription object, which has these paramethers:

|Property|Type|Default|Description |---|---|---|---| |type|string as default but it can be enum, number, etc.. ||is constant identificator of an error| |message|string||is human readable report what happend. It can be variable| |payload|any|null|here you can pass any data which help you to debug concrete problem| |previousError|Error|null|if our error is consequence of other error (e.g. error from third party package), you can use his stacktrace to know where is problem| |fingerprint|string|null|fingerprint can be used for grouping some errors together in sentry from @qest/logger-utils package|

HTTP errors

This is special errors definiton for expres, etc... We use this errors to handle error in express middleware from @qest/express-utils package, but it can be used anywhere.

This errors has property isHttp: true for better recognizing of error type.

They is descendants of BaseError and have defaults for properties, so you don't have to define type etc.

import {NotFoundError} from "@qest/error-utils"; 
export const someExpressController = (req, res, next) => {
    try {
        if(!exist){
            throw new NotFoundError({ message: 'something not exist' });
        }
    } catch (e) {
        next(e);
    }
}

Swagger documentation of HTTP errors

It can be used with our @qest/swagger-utils package. We have documentation for 2.0 and 3.0 OpenAPI definition.

How to use with @qest/swagger-utils package

First define swagger generator and load HTTP errors definitons with it.

export const swaggerGenerator = new SwaggerGenerator({   
    ...
    includePaths: ['./src', './node_modules/@qest/error-utils/dist/http-errors/doc-swagger-2.0'],   
});

Than you can use it everywhere in your swagger yamls.

paths:p
  /api/v1/something/{id}:
    get:
      produces:
        - application/json
      description: get sometginf
      parameters:
        - in: path
          name: id
          required: true
          type: string        
      responses:
        200:
          $ref: '#/responses/OurSomethingResponse'
        401:
          $ref: '#/responses/UnauthorizedError'
        404:
          $ref: '#/responses/NotFoundError'
        422:
          $ref: '#/responses/UnprocessableEntityError'