fix: return EmptyResponse instead of null on exception in NacosLoadBalancer

[daguimu]

Describe what this PR does / why we need it

In NacosLoadBalancer.getInstanceResponse(), when an exception occurs during instance selection, the method returns null instead of a proper EmptyResponse. This violates the Response<ServiceInstance> API contract and can cause NullPointerException in downstream code that calls response.hasServer() or similar methods on the returned value.

Does this pull request fix one issue?

No specific issue filed, found during code review.

Describe how you did it

Changed return null to return new EmptyResponse() in the catch block of getInstanceResponse().

Before:

catch (Exception e) {
    log.warn("NacosLoadBalancer error", e);
    return null;  // violates API contract
}

After:

catch (Exception e) {
    log.warn("NacosLoadBalancer error", e);
    return new EmptyResponse();  // consistent with the empty-instances case
}

This is consistent with the method's own behavior at line 138 where it already returns new EmptyResponse() when no instances are available.

Describe how to verify it

Run NacosLoadBalancerErrorHandlingTests — both tests pass.

Tests Added

Change Point	Test
Exception returns EmptyResponse (not null)	exceptionShouldReturnEmptyResponseNotNull()
Normal request still works correctly	normalRequestShouldReturnValidResponse()

Special notes for reviews

One-line change with minimal risk. The EmptyResponse is already used in the same method for the empty-instances case.

[uuuyuqi]

Thanks for the fix, the behavior change is correct.

One suggestion on tests: current tests verify the private helper via reflection, but the bug is observed on the public reactive path (choose()). Could we add one test that goes through choose() end-to-end (mock supplier -> non-empty instance list -> algorithm throws) and assert we get an EmptyResponse instead of an error/NPE?

This would better lock the API-level contract and prevent regressions on the actual call path.

[daguimu]

@uuuyuqi Thanks for the suggestion! I've added three end-to-end tests that go through the public choose() reactive path using StepVerifier:

• chooseShouldReturnEmptyResponseWhenAlgorithmThrows — mocks supplier with non-empty instances, algorithm throws → asserts EmptyResponse (not error/NPE)
• chooseShouldReturnValidResponseOnNormalPath — verifies normal flow returns DefaultResponse with correct host/port
• chooseShouldReturnEmptyResponseWhenNoInstances — verifies empty instance list returns EmptyResponse

The original reflection-based tests are kept alongside as a direct unit-level complement. All 5 tests pass locally.

[uuuyuqi]

LGTM