Skip to content

Latest commit

 

History

History
258 lines (141 loc) · 6.09 KB

CommandNotImplementedError.md

File metadata and controls

258 lines (141 loc) · 6.09 KB

@black-flag/coreDocs


@black-flag/core / util / CommandNotImplementedError

Class: CommandNotImplementedError

Represents trying to execute a CLI command that has not yet been implemented.

Extends

Constructors

new CommandNotImplementedError()

new CommandNotImplementedError(): CommandNotImplementedError

Represents trying to execute a CLI command that has not yet been implemented.

Returns

CommandNotImplementedError

Overrides

CliError.constructor

Defined in

src/error.ts:197

Properties

[$type]

[$type]: string[]

Overrides

CliError.[$type]

Defined in

src/error.ts:192


cause?

optional cause: unknown

Inherited from

CliError.cause

Defined in

node_modules/typescript/lib/lib.es2022.error.d.ts:24


dangerouslyFatal

dangerouslyFatal: boolean = false

This option is similar in intent to yargs's exitProcess() function, except applied more granularly.

Normally, runProgram never throws and never calls process.exit, instead setting process.exitCode when an error occurs.

However, it is at times prudent to kill Node.js as soon as possible after error handling happens. For example: the execa library struggles to abort concurrent subcommand promises in a timely manner, and doesn't prevent them from dumping output to stdout even after Black Flag has finished executing. To work around this, we can set dangerouslyFatal to true, forcing Black Flag to call process.exit immediately after error handling completes.

More generally, enabling dangerouslyFatal is a quick way to get rid of strange behavior that can happen when your microtask queue isn't empty (i.e. the event loop still has work to do) by the time Black Flag's error handling code completes. However, doing this without proper consideration of why you still have hanging promises and/or other microtasks adding work to the event loop can lead to faulty/glitchy/flaky software and heisenbugs. You will also have to specially handle process.exit when running unit/integration tests and executing command handlers within other command handlers. Tread carefully.

Inherited from

CliError.dangerouslyFatal

Defined in

src/error.ts:133


message

message: string

Inherited from

CliError.message

Defined in

node_modules/typescript/lib/lib.es5.d.ts:1077


name

name: string

Inherited from

CliError.name

Defined in

node_modules/typescript/lib/lib.es5.d.ts:1076


showHelp

showHelp: boolean = false

If true, help text will be sent to stderr before this exception finishes bubbling. Where the exception is thrown will determine which instance is responsible for error text generation.

Default

false

Inherited from

CliError.showHelp

Defined in

src/error.ts:132


stack?

optional stack: string

Inherited from

CliError.stack

Defined in

node_modules/typescript/lib/lib.es5.d.ts:1078


suggestedExitCode

suggestedExitCode: FrameworkExitCode = FrameworkExitCode.DefaultError

The exit code that will be returned when the application exits, given nothing else goes wrong in the interim.

Default

FrameworkExitCode.DefaultError

Inherited from

CliError.suggestedExitCode

Defined in

src/error.ts:131


prepareStackTrace()?

static optional prepareStackTrace: (err, stackTraces) => any

Optional override for formatting stack traces

Parameters

err: Error

stackTraces: CallSite[]

Returns

any

See

https://v8.dev/docs/stack-trace-api#customizing-stack-traces

Inherited from

CliError.prepareStackTrace

Defined in

node_modules/@types/node/globals.d.ts:28


stackTraceLimit

static stackTraceLimit: number

Inherited from

CliError.stackTraceLimit

Defined in

node_modules/@types/node/globals.d.ts:30

Methods

captureStackTrace()

static captureStackTrace(targetObject, constructorOpt?): void

Create .stack property on a target object

Parameters

targetObject: object

constructorOpt?: Function

Returns

void

Inherited from

CliError.captureStackTrace

Defined in

node_modules/@types/node/globals.d.ts:21