Closed kaero closed 9 years ago
\cc @cy6erskunk
Numeric error code is useful enough when filtering log to get subcategory of errors, for example all 63* errors. However, such error "subclasses" are hard to remember and something like error name prefixes could be used to achieve the same result. Assuming usage of prefixes, it would be nice to have some functionality allowing to avoid repetitive prefix typing (concatenation with variable looks like very poor option).
In oppose to @cy6erskunk i think that any nesting of the errors names is too complex. If we'll try to implement some sort of the error code names nesting, then it'll lead to the hell of the declaration reading and writing.
Target of dropping the error codes is to make cleaner the declarations of the errors and simple to maintain.
\cc @an9eldust
It doesn't matter what we use as a value of constants are used to get error: ResourceError.CODES.UNEXPECTED_RESULT
. So string value is more informative than number value when printing and I offer to change type of property code
of error.
Many users has notice that the pair of the class and name of the error is enough to determine error. Required numeric error codes is redundant in this case and is looks like the design mistake. I'm finally sure that we must drop them.
Let's discuss!
\cc @ruslankerimov @Flackus @ZooBestik @miripiruni