Adjust result.h error condition behavior

[alan-george-lk]

This PR addresses a minor API change around result.h (dropping noexcept label)

Context:

• Result accessors were previously marked noexcept
• clang-tidy flagged this as inaccurate because std::get on a std::variant can throw a std::bad_variant_access if the type being accessed doesn't match the position

Considered alternatvies:

• Keeping noexcept but using something like std::get_if (doesn't throw) --> declined due to dereferencing nullptr to maintain API signature
• Switching away from std::variant entirely to avoid to avoid this issue --> declined because it still doesn't address the root issue, which is accessing an error result on success and vice-versa
• Adjusting the API to return std::optional for accessors --> declined as too impactful to API, and conditionals ok() and has_error() already exist, would be redundant

Decision:

• result.h accessor methods drop noexcept
• Throw an exception with a message ourselves vs. going through std::get (users can't do much with a generic std::bad_variant_access exception with no message)

Impact:

This only affects users of result.h that were expecting an exception-free experience, which is negligible if not completely nonexistent at this point in the SDK maturity. In the existing version before this PR, the exception would still actually be thrown if the wrong type was accessed, even though it was marked noexcept.

Testing

• Additional unit tests to cover this flow

[stephen-derosa]

nice LGTM

[stephen-derosa]

dang nice find, are you planning on doing this as a part of this work? If not, consider making a ticket to track

[alan-george-lk]

I think I'm going to update examples first, then adjust that in this PR, that way there's not 3 total PRs

[xianshijing-lk]

One question, lgtm in general

[xianshijing-lk]

Question:
do we such overload ? any existing use case ?

I wonder if we should just remove the const T&& / const E&& overloads since they do not bring much practical benefit

[alan-george-lk]

@stephen-derosa any insight here? I agree not a ton of value for such a small data structure. Gonna assume this was agentic thorough-ness and not intentional

[stephen-derosa]

this was agentic as future proofing -- but i agree i think its over-engineered