[Ingest Manager] Define custom errors by extending Error

[jfsiii]

Summary

Create Error types using extends. e.g. define new types with

class SomeNewError extends Error {}
// or
class SomeNewError extends IngestManagerError {}

and create with

new SomeNewError('a message')

Why this way?

• We do this in a few places already:

  • kibana/x-pack/plugins/ingest_manager/server/services/epm/packages/index.ts

    Lines 39 to 43 in 2685654

    	export class PackageNotInstalledError extends Error {
    	constructor(pkgkey: string) {
    	super(`${pkgkey} is not installed`);
    	}
    	}

  • kibana/x-pack/plugins/ingest_manager/server/services/agents/checkin/rxjs_utils.ts

    Line 8 in 0c47747

    export class AbortError extends Error {}

• It is compatible with the recommendation/example from Platform [Ingest Manager] Error handling in server APIs #66688 (comment)
• It's the recommended / common example approach from TypeScript
  • https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-2.html
  • https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#extending-built-ins-like-error-array-and-map-may-no-longer-work
• We can maintain type safety and combine/filter more easily than with enum
• IMO, new CustomError('string') is a better experience than new CustomError(CustomTypes.type, 'string')

[jfsiii]

@elasticmachine merge upstream

[jfsiii]

I chose to extend IngestManagerError here so that it gets the benefits of the stack trace naming from https://github.com/elastic/kibana/pull/69966/files#diff-305aab707fa2746fa91c6bec9e78c0b7R11 and remain an IngestManagerError

However, even if it did extend Error we could make a type like

type IngestManagerErrorType = IngestManagerError | RegistryError

This is where my mind is heading now. Files will define/export Errors where they are used (or perhaps lifted to common or server), and then those can be imported and combined into other types

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[jfsiii]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 9dc0992

Build metrics

✅ unchanged

History

• 💚 Build #56837 succeeded b2a620d
• 💚 Build #56364 succeeded d67910a

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[nchaulet]

LGTM 🚀 It's nice to make things more "standard"

[jfsiii]

I'm going to merge this so I can use this pattern in some other places, and because it's not difficult to roll back, but I'm happy to revisit this if anyone wants.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 69966 or prevent reminders by adding the backport:skip label.