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
Currently, we have an implicit contract that success return code should be 0, and failure return codes should be negative. Hence, we can composite error code when calling child functions by returning child_error_code * 10 + my_error_code, and do it recursively. For example, our mqbc::StorageManager defines an RcEnum of -4 through 0. If it calls another function and fails, it composites the error code as follows:
int rc = StorageUtil::validatePartitionDirectory(partitionCfg,
errorDescription);
if (rc != rc_SUCCESS) {
return rc * 10 + rc_PARTITION_LOCATION_NONEXISTENT; // RETURN
}
However, there are flaws to this design:
The implicit contract of negative error code is fragile. If someone accidentally adds a positive failure return code, there is no check and it would mess up the composite error code logic.
The enum RcEnum are defined per function and thus only makes sense within the context of the specific function.
Describe the solution you'd like
We are looking for design proposals for better error code management. We welcome a dedicated class for error code if it makes things easier. The design should have an explicit contract that can be validated, and should allow for composite error codes.
Please discuss with us before implementing the solution.
Alternatives you considered
No response
The text was updated successfully, but these errors were encountered:
Is there an existing proposal for this?
Is your feature request related to a problem?
Currently, we have an implicit contract that success return code should be 0, and failure return codes should be negative. Hence, we can composite error code when calling child functions by returning
child_error_code * 10 + my_error_code
, and do it recursively. For example, ourmqbc::StorageManager
defines anRcEnum
of -4 through 0. If it calls another function and fails, it composites the error code as follows:However, there are flaws to this design:
enum RcEnum
are defined per function and thus only makes sense within the context of the specific function.Describe the solution you'd like
We are looking for design proposals for better error code management. We welcome a dedicated class for error code if it makes things easier. The design should have an explicit contract that can be validated, and should allow for composite error codes.
Please discuss with us before implementing the solution.
Alternatives you considered
No response
The text was updated successfully, but these errors were encountered: