[AI Task] [Tizen.Network.Connection] ThrowConnectionException: switch expression with default arm

[JoonghyunCho]

Summary

ConnectionErrorFactory.ThrowConnectionException had a 14-case switch statement with no default branch. Any unrecognized native error code (e.g. a future native lib addition) caused the method to silently return, letting callers continue past a failed native call as if the call had succeeded — typically resulting in a downstream NRE or a wrong "successful" result.

This PR converts the body to a throw <expr> switch { ... } expression with an explicit default arm. The compiler now enforces exhaustiveness, preventing the silent-failure bug from regressing.

Changes

• src/Tizen.Network.Connection/Tizen.Network.Connection/ConnectionError.cs — ThrowConnectionException rewritten as a switch expression with a _ => new InvalidOperationException($"Unknown ConnectionError({errno}) {message}".TrimEnd()) default arm. All 15 known cases preserve their original exception type and message verbatim.

Mode

Refactoring (with a deliberate, scoped behavior change for the unknown-errno case)

Behavior change scope

• Known error codes (15 cases): exception type + message unchanged.
• Unknown error codes (previously silent return): now throw InvalidOperationException with the errno embedded in the message. This is the intended fix — the issue documents that downstream code in this assembly already breaks on the silent-return path (NRE / wrong result), so making the failure visible is strictly an improvement.
• ConnectionError.None (success): never reaches this method in any in-tree caller. All ~30 call sites are guarded by if ((ConnectionError)ret != ConnectionError.None) before invoking. Verified by grep: no caller passes 0 / ConnectionError.None. The two Check* helpers also guard on the specific error before calling.

API Compatibility

• Public API signatures: unchanged (method is internal static)
• Tizen API Level: no impact
• Native interop: no impact

Verification

• Build: passed (dotnet build src/Tizen.Network.Connection/Tizen.Network.Connection.csproj — 0 errors; pre-existing unrelated warnings only)
• Tests: N/A (no unit tests for this internal factory; behavior change is targeted at the previously unreachable silent path)
• Benchmark: N/A (error path; not on any hot path)

Fixes #7591

[gemini-code-assist]

Code Review

This pull request refactors the ThrowConnectionException method in ConnectionError.cs to use a switch expression and introduces a default case for unknown error codes. The review feedback highlights an opportunity to improve consistency by using string interpolation and TrimEnd() for all error cases that include the optional message, preventing trailing spaces when the message is empty.

[gemini-code-assist]

The new default case (_) correctly uses TrimEnd() to handle the optional message parameter without leaving a trailing space. However, other cases like InvalidOperation, NotSupported, and PermissionDenied still use string concatenation ("... " + message), which results in a trailing space when message is empty. Additionally, InvalidParameter currently ignores the message entirely. For consistency and better error reporting, consider using the same interpolation pattern for all cases that can include additional context.

                ConnectionError.AddressFamilyNotSupported => new InvalidOperationException("Address Family Not Supported"),
                ConnectionError.AlreadyExists             => new InvalidOperationException("Already Exists"),
                ConnectionError.DhcpFailed                => new InvalidOperationException("DHCP Failed"),
                ConnectionError.EndOfIteration            => new InvalidOperationException("End Of Iteration"),
                ConnectionError.InvalidKey                => new InvalidOperationException("Invalid Key"),
                ConnectionError.InvalidOperation          => new InvalidOperationException($"Invalid Operation {message}".TrimEnd()),
                ConnectionError.InvalidParameter          => new ArgumentException($"Invalid Parameter {message}".TrimEnd()),
                ConnectionError.NoConnection              => new InvalidOperationException("No Connection"),
                ConnectionError.NoReply                   => new InvalidOperationException("No Reply"),
                ConnectionError.NotSupported              => new NotSupportedException($"Unsupported feature {message}".TrimEnd()),
                ConnectionError.NowInProgress             => new InvalidOperationException("Now In Progress"),
                ConnectionError.OperationAborted          => new InvalidOperationException("Operation Aborted"),
                ConnectionError.OperationFailed           => new InvalidOperationException("Operation Failed"),
                ConnectionError.OutOfMemoryError          => new OutOfMemoryException("Out Of Memory Error"),
                ConnectionError.PermissionDenied          => new UnauthorizedAccessException($"Permission Denied {message}".TrimEnd()),
                _                                         => new InvalidOperationException($"Unknown ConnectionError({errno}) {message}".TrimEnd())

[JoonghyunCho]

🤖 [AI Review]
Addressed in f87ee3b. Applied the suggested interpolation with .TrimEnd() to InvalidOperation, InvalidParameter, NotSupported, and PermissionDenied for consistent error formatting.

[JoonghyunCho]

🤖 [AI Review]

Reviewed — no findings.

Scope checked:

• 15-arm switch expression preserves exception type and message verbatim for every known ConnectionError case (compared 1-to-1 against the original switch statement).
• New _ default arm closes the prior silent-return failure mode for unrecognized errno; the embedded errno/message formatting is correctly TrimEnd()-ed only on the default path so known arms remain byte-identical.
• Method is internal static — public API surface unchanged; ~30 call sites already guard with if ((ConnectionError)ret != ConnectionError.None) per the PR description, so the new exhaustive throw cannot regress success paths.
• Switch expression syntax (C# 8+) and target-typed exception construction are supported on the module's TFM.

No 🔴 critical issues, no 🟡 suggestions to flag.

---

Automated review — final merge decision rests with human reviewers.