Skip to content

Errors API #804

@OmarTawfik

Description

@OmarTawfik

Instead of an Error type, I suggest moving to Diagnsotic notation, popularized by Roslyn, TypeScript, VS Code, and others.

  • Diagnostic::message() -> String to return a human readable string, usable in editors and downstream APIs.
  • Diagnostic::kind() -> DiagnosticKind to return an enum: ParserError, ValidationError, etc...
  • Diagnostic::code() -> String the string represenatation of DiagnosticKind, suitable to surface in editors and URLs (error glossary/wiki).
  • Diagnostic::severity() -> DiagnosticSeverity to return an enum: Error, Warning, Info, etc... (same as LSP severity levels)
  • Diagnostic::location() for file/range info.

As for the errors API:

  • Remove ariadne reports from the API (should only be the CLI).
  • CLI-specific error codes, and unified representation (like FileNotFound), instead of just panicking.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions