Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design for robust composite error codes #403

Open
1 task done
kaikulimu opened this issue Aug 22, 2024 · 0 comments
Open
1 task done

Design for robust composite error codes #403

kaikulimu opened this issue Aug 22, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@kaikulimu
Copy link
Collaborator

kaikulimu commented Aug 22, 2024

Is there an existing proposal for this?

  • I have searched the existing proposals

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, 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:

  1. 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.
  2. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant