Currently the codes for uncaught exceptions include the class name, for example "internal_api_error_ReadOnlyError", or "internal_api_error_DBQueryError", or possibly something like "internal_api_error_MediaWiki\Namespace\FooBarException". As you can see in that last example, that can get rather ugly and complicates recent attempts to verify that all error codes use a restricted character set. Thus, we are deprecating these error codes. In the future all such errors will use the code "internal_api_error". The date for that change has not yet been set. If a client for some reason needs to see the class of the uncaught exception, this is available in a new 'errorclass' data property in the API error. This will be returned beginning in 1.33.0-wmf.8 or later, see https://www.mediawiki.org/wiki/MediaWiki_1.33/Roadmap for a schedule. Note that database errors will report the actual class, such as "MediaWiki\rdbms\DBQueryError", rather than the old unprefixed name that had been being maintained for backwards compatibility. Clients relying on specific internal error codes or detecting internal errors by looking for a "internal_api_error_" prefix should be updated to recognize "internal_api_error" and to use 'errorclass' in preference to using any class name that might be present in the error code. In JSON format with errorformat=bc, an internal error might look something like this: { "error": { "code": "internal_api_error_InvalidArgumentException", "info": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing", "errorclass": "InvalidArgumentException", "trace": "InvalidArgumentException at ..." }, "servedby": "hostname" } With modern errorformats, it might look like this: { "errors": [ { "code": "internal_api_error_InvalidArgumentException", "text": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing", "data": { "errorclass": "InvalidArgumentException" } } ], "trace": "InvalidArgumentException at ...", "servedby": "hostname" } -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation