Skip to content

examples: Use std::expected in shared and util#2077

Merged
tatsuhiro-t merged 1 commit intomainfrom
examples-expected-shared-util
Mar 20, 2026
Merged

examples: Use std::expected in shared and util#2077
tatsuhiro-t merged 1 commit intomainfrom
examples-expected-shared-util

Conversation

@tatsuhiro-t
Copy link
Copy Markdown
Member

No description provided.

@tatsuhiro-t tatsuhiro-t added this to the v1.22.0 milestone Mar 20, 2026
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the error handling strategy within the examples directory by adopting std::expected<T, Error> for functions that previously relied on integer return codes. This change enhances the clarity and safety of error propagation, making it explicit when an operation might fail and what kind of error occurred. The update improves code readability and maintainability by providing a modern, type-safe mechanism for handling potential failures.

Highlights

  • Modernized Error Handling: Migrated numerous utility functions from returning integer error codes to using std::expected<T, Error> for improved type safety and explicit error propagation.
  • Enhanced Error Reporting: Introduced new Error enum values, CRYPTO and SYSCALL, to provide more granular and descriptive error information for cryptographic and system call failures.
  • Refactored Network Utilities: Updated network-related functions, including socket creation and local address retrieval, to leverage std::expected for clearer success/failure states and consistent error handling.
  • Consistent Call Site Updates: Adjusted all call sites in client and server examples to correctly process the new std::expected return types, ensuring robust error checking throughout the codebase.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors several functions in the shared and util libraries to use std::expected for error handling, which is a great improvement for code clarity and safety. The changes are mostly correct and consistently applied across the examples. However, I found a critical bug in make_socket_nonblocking that causes it to always return an error, and another issue where the return value of this function is not checked in create_nonblock_socket. I've added comments with suggestions to fix these issues.

return std::unexpected{Error::SYSCALL};
}

make_socket_nonblocking(fd);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The return value of make_socket_nonblocking is not checked. Since it now returns a std::expected, you should check for an error and handle it appropriately (e.g., by closing the file descriptor and propagating the error).

  if (auto res = make_socket_nonblocking(fd); !res) {
    close(fd);
    return std::unexpected{res.error()};
  }

@tatsuhiro-t tatsuhiro-t force-pushed the examples-expected-shared-util branch from d209853 to d2fedc2 Compare March 20, 2026 07:59
@tatsuhiro-t tatsuhiro-t merged commit 08be23d into main Mar 20, 2026
73 checks passed
@tatsuhiro-t tatsuhiro-t deleted the examples-expected-shared-util branch March 20, 2026 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant