[AI Task] [Tizen.Network.Connection] Stop swallowing native exceptions in event accessors

[JoonghyunCho]

Summary

Removes the broad catch (Exception) swallow blocks in the four internal event accessors of ConnectionInternalManager, so that native registration / deregistration failures propagate to callers instead of producing a silent log-only failure.

Changes

• src/Tizen.Network.Connection/Tizen.Network.Connection/ConnectionInternalManager.cs
  • ConnectionTypeChanged (add / remove): drop try/catch wrapping ConnectionTypeChangedStart() / ConnectionTypeChangedStop().
  • IPAddressChanged (add / remove): drop try/catch wrapping IPAddressChangedStart() / IPAddressChangedStop().
  • EthernetCableStateChanged (add / remove): drop try/catch wrapping EthernetCableStateChangedStart() / EthernetCableStateChangedStop().
  • ProxyAddressChanged (add / remove): drop try/catch wrapping ProxyAddressChangedStart() / ProxyAddressChangedStop().

Total: 8 try/catch blocks removed (~75% reduction in lines for those accessors). Log.Error already exists inside the *Start / *Stop helpers themselves, so diagnostics are preserved. The exception type and message thrown by ConnectionErrorFactory.ThrowConnectionException are unchanged.

Mode

Refactoring (Option A from the issue: propagate exceptions). No public API signatures change. Behaviorally, ConnectionTypeChanged and EthernetCableStateChanged previously swallowed native registration failures (silent failure path); the change surfaces those failures to callers — this is the intended bug-visibility fix.

Verification

• Build: passed (dotnet build src/Tizen.Network.Connection/Tizen.Network.Connection.csproj — 0 errors, 0 warnings)
• Tests: N/A (no unit-test project covers this internal manager)
• Benchmark: skipped — change is on the event registration code path, not a hot path; runtime impact is not the goal of the issue (flagged as code-quality / latent-bug). On-device benchmark also requires sdb device access, which is not available in this environment.

API compatibility note

ConnectionInternalManager is an internal sealed singleton, but its events are surfaced by Tizen.Network.Connection.Connection to user code. Callers of += handler on the corresponding public events may now observe exceptions (e.g., NotSupportedException, InvalidOperationException) where they previously saw a silent log + no registration. This is a behavioral change and intentional — see the issue for rationale. Migration / release-note coverage recommended.

Fixes #7593

[gemini-code-assist]

Code Review

This pull request removes several try-catch blocks within event accessors in ConnectionInternalManager.cs to facilitate exception propagation during event registration and deregistration. The review feedback points out that the underlying helper methods for IPAddressChanged and ProxyAddressChanged still need to be updated to throw exceptions on native failures, as they currently only log errors, which prevents the intended propagation from occurring for those specific events.

[gemini-code-assist]

While removing the try-catch block here is correct to allow exception propagation, the underlying IPAddressChangedStart() method (lines 272-294) and its counterpart IPAddressChangedStop() (lines 296-304) do not currently call ConnectionErrorFactory.ThrowConnectionException(ret) on failure. To fully achieve the goal of propagating native failures to callers, these helper methods should be updated to throw exceptions when the native registration/deregistration fails, maintaining consistency with ConnectionTypeChangedStart and EthernetCableStateChangedStart.

[JoonghyunCho]

🤖 [AI Review]
Addressed in 6dd2831. IPAddressChangedStart and IPAddressChangedStop now call ConnectionErrorFactory.ThrowConnectionException(ret) on failure.

[gemini-code-assist]

Similar to the IPAddressChanged event, the ProxyAddressChangedStart() (lines 332-354) and ProxyAddressChangedStop() (lines 356-364) methods currently only log errors without throwing exceptions. Removing the try-catch block in this accessor won't result in exception propagation for native failures until these helper methods are updated to call ConnectionErrorFactory.ThrowConnectionException(ret).

[JoonghyunCho]

🤖 [AI Review]
Addressed in 6dd2831. ProxyAddressChangedStart and ProxyAddressChangedStop now call ConnectionErrorFactory.ThrowConnectionException(ret) on failure.

[JoonghyunCho]

🤖 [AI Review]

Reviewed — no findings.

Scope checked:

• 8 try/catch removals across 4 event accessor pairs (ConnectionTypeChanged, EthernetCableStateChanged, IPAddressChanged, ProxyAddressChanged) — symmetric add/remove handling preserved.
• On the add path, the prior return; (skip subscription on error) is equivalent to throwing before _X += value; runs — net effect on internal state matches.
• On the remove path, _X -= value; runs before *Stop() so user-handler removal still completes if *Stop() throws — backing field correctness preserved.
• *Start/*Stop helpers retain their own Log.Error + ConnectionErrorFactory.ThrowConnectionException(ret) (verified at HEAD), so diagnostics are not lost.
• No public API signatures changed (ConnectionInternalManager is internal sealed); behavioral surface change to Tizen.Network.Connection.Connection callers is intentional per the linked issue.
• Pre-existing finalizer path (UnregisterEvents() called from ~ConnectionInternalManager) is not touched and not made worse by this PR.

No 🔴 critical issues, no 🟡 suggestions to flag.

---

Automated review — final merge decision rests with human reviewers.

[JoonghyunCho]

🤖 [AI Review]
Addressed review feedback in commit 6dd2831. Both IPAddressChangedStart/Stop and ProxyAddressChangedStart/Stop now call ConnectionErrorFactory.ThrowConnectionException(ret) on native failure, so removing the try-catch blocks in the event accessors actually propagates errors as intended.