Andreas Färber <afaer...@suse.de> writes: > Am 10.02.2014 10:20, schrieb Markus Armbruster: [...] >> You're right to challenge new uses of QERR_*, but the use you spotted is >> appropriate, since we want consistency with the existing visitors. > > OK, I still don't fully understand the logic why sometimes we shouldn't > use QERR_ at all, in some cases inline the error message for > compatibility without reusing the QERR_ and sometimes can use QERR_ > directly, but I don't mind it getting applied that way - QERR_ is not my > fight. :)
The general rule is to use ERROR_CLASS_GENERIC_ERROR except when backward compatibility with existing usage requires another class. Corollary: prefer error_setg() over error_set() then. Corollary: prefer not to use the QERR_ macros then. However, other considerations can overrule this preference. Not the rule, though! In this particular case, the existing visitor code in the same file uses QERR_INVALID_PARAMETER_TYPE (which has ERROR_CLASS_GENERIC_ERROR), and the patch mimicks them for consistency. [...]
