Skip to content

Use error names instead of error codes

Administrator requested to merge error-names into master

Created by: felixfbecker

Errors in ECMAScript have a message and a name. code is something Node-specific (ErrNoException interface in TS), and those errors still all have name. Native errors like TypeError, URIError, AggregateError (coming soon) all only have name.

When we send errors to/from background pages or web workers, we can only reasonably expect name to be present, so we should never rely on code. See e.g. https://github.com/mozilla/webextension-polyfill/issues/210 or comlink source code. This is a preliminary requirement to fix and prevent bugs like https://github.com/sourcegraph/sourcegraph/issues/9411.

Using both in our codebase inconsistently opens the risk to checking for the wrong property, (especially because errors are any in TypeScript) and adds additional code.

This change removes all uses of code in favor of name. There is still a case for having name be optional (e.g. GraphQL errors don't have a name, but do have message), so ErrorLike is still kept for now but we could think about just using the native Error interface in the future.

The error code constants were following NodeJS/Unix errno conventions, which don't make a lot of sense for error names and can become very unreadable. I propose the more readable CONSTANT_CASE we use elsewhere.

Depends on https://github.com/sourcegraph/codeintellify/pull/240

Merge request reports

Loading