refactor: Error constructors do not need new

[erights]

See endojs/endo#1562

A step towards turning on more @jessie-check directives. See #3876 and #5497

Jessie prohibits new. One trivial case of revising code to conform is to remove the new on calls to the *Error( constructors. For these specifically, their construct behavior is the same as their call behavior. This also gets rid of a bit of visual noise, make code a bit more readable.

Note to reviewers: I isolated this step by itself because

• I did this in a purely mechanical manner. At least so far, as of this first commit, before responding to any review comments
• IIUC, it should be clearly correctness preserving, without requiring much understanding of the code being refactored.

[erights]

Aha! As discovered from looking at CI errors, not all *Errors mentioned by our sources are builtin errors, or adequately like builtin errors. Specifically, CommanderError is a JS subclass of Error and InvalidArgumentError is a JS subclass of CommanderError. These are both apparently from https://github.com/tj/commander.js/ , which is used by both endo cli and agoric-sdk agoric-cli .

[dckc]

Why do this in files that aren't marked @jessy-check? What keeps them from coming back?

[erights]

For general stylistic consistency, and as a step towards being able to add @jessie-check to more files. Even for the files we aren't yet able to mark @jessie-check, we want as much stylistic consistency as practical with those we do.

[dckc]

I don't disagree, but it's not clear to me how other reviewers will learn this new part of house style. I don't see what keeps the new operators from re-appearing since, evidently, folks are used to putting them there.

Perhaps add a few reviewers to get a critical mass? In particular, kernel maintainers.

Or discuss it internally?

[FUDCo]

I've been doing Error(...) instead of new Error(...) for as long as I can remember.

[FUDCo]

This makes me happy.