Skip to content

Latest commit

 

History

History
42 lines (30 loc) · 2.09 KB

app-error.md

File metadata and controls

42 lines (30 loc) · 2.09 KB

NodeKit: AppError

It's often happens in applications that you want to attach some information to the error that you're throwing. Sometimes this can lead to the situtaion when application throws not error but object — which is a bad way to deal with this since you're losing a stacktrace.

AppError is an extension of the standard Error class. It provides a way to attach data to the error object and also provides a few useful functions.

Examples:

import {AppError} from '@gravity-ui/nodekit';

// It can be used just like a simple Error
throw new AppError('Something happened');

// But you can also attach some information to the instance
throw new AppError('Something happened', {
  // "code" field is a way to distinguishing different kind of errors
  // in your application. It's recommended to use string constants for it.
  code: 'ERR.REQUEST_DENIED',

  // "details" is an object typed via generic that you can use to store some
  // additional information related to the object, like userId or processing timings.
  // It's recommended not to store here secret or internal information since "details"
  // from the error can be used by your application for generating response to the user
  details: {},

  // "debug" is similar to details, but it's untyped (object) and dedicated for internal
  // information that can help debugging the problem but should not leak to the user.
  debug: {},

  // NodeKit does not handle "code", "details" and "debug" in some kind of special way by itself,
  // you can use them as you want, but we're recommend sticking to the guideline
});

// Checking if value is an AppError instance (this helper is also a type guard)
AppError.isAppError(err);

// Wrapping error with AppError and attaching data alongside it
throw AppError.wrap(error, {code: 'ERR.REQUEST_DENIED'});

When wrapping axios error, AppError extracts request url, response status and also request id and trace id (if present) from the axios error instance and places them into "debug" field. In the future we'll allow extending this logic in plugins to understand more types of special libary errors.