It's probably vaguely preferable to just throw new Exception(...) instead of defining an error type in new code, unless you have a specific scenario in mind for client error handling behavior.

The error type stuff is mostly a legacy system (not usually used by newer API calls) that sounded good in theory but was bad in practice, and adding more of it probably just makes it harder to clean up without helping anyone implement any behavior. In practice the overwhelming majority of errors are effectively just "wrong/bad parameters", and essentially no client will reasonably do anything special with a "bad name parameter" error versus a "bad file data" parameter versus a "missing required parameter" error or whatever.

(If clients did care about this some day, it would probably be better to bundle them all into some kind of "parameter validation" meta-error that lists the fields in a machine-readable format, instead of having hundreds of "ERR-NO-WHATEVER" constants that clients would need to hard-code to handle.)

There are a small number of cases where clients reasonably care (the one I can remember offhand is authentication-related errors) but even these would probably be better exposed in some other meta-error-way.

The most-desirable form for all of this is probably a small set of machine-readable meta-errors (authentication, policy error, temporary/retryable service failure, parameter validation) that are easy to implement on the server side (don't require defining custom error codes for every error). And all the parameter validation should be made easy/automatic via a mechanism like PhutilTypeSpec::checkMap().

Per above, consider just reverting this and leaving a bare exception.

Boy howdy, the ol' error system ain't so great.