You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Various functions currently return an error_result with an optional error string. This is readable and nice in the debugger but it is unfortunately not very friendly for a few reasons.
Searching the documentation or on google for an error string is more complicated
It is not possible to reliable branch on an error result string as it could change during a minor update
Handling of errors is awkward
It is harder to maintain a translation into non-English languages
Instead, a proper error code similar to Windows error codes should be used. A single typed enum with value ranges reserved for certain things.
Zero init should represent an unknown error.
One should represent success.
Negative (and zero) values can represent error codes.
A free standing to_string(enum value) function can be introduced to convert error codes to readable strings.
This will represent an API break which is not ideal. As such, we should target 3.0 for a full migration.
We could do this earlier by introducing a shim that coerces to the old type and the new type automatically and forwards the few functions calls we currently have to sensible defaults. A deprecation warning could be added.
The text was updated successfully, but these errors were encountered:
Various functions currently return an error_result with an optional error string. This is readable and nice in the debugger but it is unfortunately not very friendly for a few reasons.
Instead, a proper error code similar to Windows error codes should be used. A single typed enum with value ranges reserved for certain things.
Zero init should represent an unknown error.
One should represent success.
Negative (and zero) values can represent error codes.
A free standing
to_string(enum value)
function can be introduced to convert error codes to readable strings.This will represent an API break which is not ideal. As such, we should target 3.0 for a full migration.
We could do this earlier by introducing a shim that coerces to the old type and the new type automatically and forwards the few functions calls we currently have to sensible defaults. A deprecation warning could be added.
The text was updated successfully, but these errors were encountered: