Page MenuHomePhabricator

Use error codes in the API, rather than error messages
Open, HighPublic

Description

Using error messages as a way of transmitting machine-readable data is unacceptable. It is simply against every convention or logic ever. Integer codes should be used. A human-readable field could be provided alongside, if you want. An example of this human readable checking is on https://phabricator.wildfyre.net/source/libwf-java/browse/master/src/main/java/net/wildfyre/areas/Area.kt$122. Instead, there should be a dictionary to convert integer codes to human readable error messages, but this dictionary should not be used in the code. This dictionary should be purely a part of the API (java bit I mean) provided as a convenience to clients.

Event Timeline

Hackintosh5 triaged this task as High priority.Feb 27 2019, 8:58 AM
Hackintosh5 created this task.
Info-Screen added a subscriber: Info-Screen.

Server API already sends a code (known as http status code) errors start with 4 (client errors, e.g. invalid input) or 5 (server errors, e.g. database unavailable)

CLOVIS added a subscriber: CLOVIS.Feb 27 2019, 1:21 PM

Server API already sends a code (known as http status code) errors start with 4 (client errors, e.g. invalid input) or 5 (server errors, e.g. database unavailable)

That error code lacks precision and is not explicit enough about the exact problem.

Since we already send a JSON error message with a "details" field, we could add a "code" field with just a number.

I don't think it's a good idea to remove the current system, but adding a simple integer field sounds sensible while being backward-compatible