new-error - npm Package Compare versions

Comparing version 1.0.6 to 1.0.7

CHANGELOG.md

package.json

		{
		"name": "new-error",
		"version": "1.0.6",
		"version": "1.0.7",
		"description": "A production-grade error creation and serialization library designed for Typescript",
		@@ -5,0 +5,0 @@ "main": "build/index.js",

README.md

		@@ -24,2 +24,3 @@ # new-error
		<!-- TOC -->
		- [Motivation / Error handling use-cases](#motivation--error-handling-use-cases)
		- [Installation](#installation)
		@@ -51,2 +52,19 @@ - [Example Usage](#example-usage)

		# Motivation / Error handling use-cases

		The basic Javascript `Error` type is extremely bare bones - you can only specify a message.

		In a production-level application, I've experienced the following use-cases:

		- A developer should be able to add metadata to the error that may assist with troubleshooting.
		- A developer should be able to reference the original error.
		- Errors should be able to work with a logging framework.
		- Errors should be well-formed / have a defined structure that can be consumed / emitted for analytics and services.
		- Errors should not expose sensitive data to the end-user / client.
		- Errors that are exposed to the end-user / client should not reveal data that would expose system internals.
		- Error responses from an API service should follow a common format.
		- End-users / clients should be able to relay the error back to support; the relayed data should be enough for a developer to troubleshoot.

		`new-error` was built with these use-cases in mind.

		# Installation
		@@ -496,2 +514,10 @@
		}

		// You'll need to modify code below to best fit your use-case
		// err.message could potentially expose system internals
		return res.json({
		err: {
		message: err.message
		}
		})
		}
		@@ -498,0 +524,0 @@

New alerts