Skip to content
The style guide is in beta: content and structure may change.

Errors and exceptions

An error entry is read at the worst moment, when the call has already failed. It has to say why, and what to do next, in that order. These rules cover the errors section of a reference page; how a method behaves when a dependency is missing is part of its description (api-member-005).

Document each error with its cause and the caller’s remedy

Section titled “Document each error with its cause and the caller’s remedy”
api-error-001 should API docs

List every error, exception, or error code that the element can produce, each with the condition that causes it and what the caller can do about it. Title the section by the language’s or platform’s convention: Exceptions, Errors, Throws, or Error codes.

Examples

  • PermissionError: The caller lacks the contacts.read permission. Request the permission, then retry the call.
  • PermissionError: Thrown when there is a permission error.
  • 404 NOT_FOUND: No project has the specified ID. Check the ID against the project list.

Rationale

A reader who hits an error wants two things: to recognize the cause in their own code, and to know the next step. The section title follows the language because that is the word the reader’s stack trace or response body uses.