Better way to handle Error messages

[Souvikns]

I and @magicmatatjahu were talking about this. We can improve the way error messages are handled. Right now there are a bunch of try/catch blocks making the code messy. Also, the error is generated from separated places. Would be better to have a discussion on this.

[magicmatatjahu]

My main idea would be to cache (buffor) errors and display them at the end of command execution. Maybe something like event sourcing would help.

[Souvikns]

My main idea would be to cache (buffor) errors and display them at the end of command execution. Maybe something like event sourcing would help.

@magicmatatjahu can you give an example or share any good writeup that would help me understand the concept.

[Souvikns]

Should we close this, oclif is handling this.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[Souvikns]

The errors from CLI can be classified into two distinct types, cli specific like loading spec files and context error, etc, and command specific like errors from validation errors from the studio. So we could divide our errors according to these classifications. So we need to provide an interface for contributors to create their own errors for their commands.

I propose something like this

interface IBaseError {
  message: string
  exit: number
  suggestions?: string[]
}

interface IError {
  message: string | Error
  options: {
    exit: number
    suggestions?: string[]
  }
}

abstract class BaseError implements IBaseError {
  message = "Unknown Error occured";
  exit = 1;
  suggestions?: string[]

  getError(): IError {
    return {
      message: this.message,
      options: {
        exit: this.exit,
        suggestions: this.suggestions
      }
    }
  }
}

class ContextNotFoundError extends BaseError {
  constructor(contextName: string) {
    super();
    this.message = `Context ${contextName} does not exist`;
    this.exit = 3
  }
}

try {
  throw new ContextNotFoundError('Code')
}catch (e) {
  if (e instanceof BaseError) {
    console.log(e.getError())
  }
}

Modeling the interfaces from https://oclif.io/docs/commands#thiserrormessage-string--error-options-code-string-exit-number-ref-string-suggestions-string.

Also for exit codes, we might need to discuss and document exit codes for different errors.

@magicmatatjahu @peter-rr what do you think?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart: