Exception Handling (Exception Suppression)

When sending an HTTP remote request, you may encounter the following exceptional situations:

The target host is unreachable
The request is canceled
The request times out
Other network exceptions

By default, these exceptions interrupt program execution. To improve system robustness, the framework provides the following exception handling solutions:

1. Basic exception catching (try/catch pattern)

1234567891011

try{    var httpResponseMessage = httpRemoteService.SendAsync(HttpRequestBuilder.Post("https://furion.net/");}catch(Exception ex){    var httpResponseMessage = ex.GetResponseMessage();  // You can obtain the HttpResponseMessage? object via the extension    var requestDuration = ex.GetRequestDuration();  // You can obtain the request duration (milliseconds) via the extension    // Exception handling logic (such as logging, fallback handling)}

Applicable scenarios: when precise control over exception handling logic is required (such as recording specific exception logs, performing compensation operations).

2. Exception suppression (silent mode)

Although developers usually use try/catch for exception handling, in certain scenarios we prefer that exceptions silently return null without interrupting the flow. For this purpose, the framework provides a flexible exception suppression feature.

Suppress all request exceptions

var httpResponseMessage = httpRemoteService.SendAsync(HttpRequestBuilder.Post("https://furion.net/")    .SuppressExceptions());  // Suppress all exceptions

When an exception occurs in the request, the code does not interrupt but returns null, meaning the value of httpResponseMessage is null.

In certain scenarios, we want to suppress the exception while still being able to capture the exception information (for example to record it in the log) without interrupting the normal execution of the program. In this case, you can achieve this via the SetOnRequestFailed callback:

HttpRequestBuilder.Post("https://furion.net/")    .SuppressExceptions()    .SetOnRequestFailed((exception, responseMessage) =>     // Note: responseMessage may be empty    {        Console.WriteLine(exception.Message);    });

This method allows you to safely handle error information after the exception is suppressed, and is suitable for logging, monitoring, or other error response logic.

Suppress only specific types of exceptions

The framework also supports suppressing only specific types of exceptions. For example, you can suppress only timeout exceptions and request cancellation exceptions:

var httpResponseMessage = httpRemoteService.SendAsync(HttpRequestBuilder.Post("https://furion.net/")    .SuppressExceptions([typeof(TimeoutException), typeof(TaskCanceledException)]));  // Suppress timeout and cancellation exceptions

Disable exception suppression configuration

If you need to restore the default behavior (i.e., interrupt the program when an exception occurs), you can explicitly disable exception suppression:

var httpResponseMessage = httpRemoteService.SendAsync(HttpRequestBuilder.Post("https://furion.net/")    .SuppressExceptions(false);  // Restore the default configuration

This configuration is equivalent to not calling SuppressExceptions(); when any exception occurs, program execution will be interrupted.

Precautions

When enabling the exception suppression feature, please note the following:

Override rule
When SuppressExceptions() or related configuration is called multiple times, only the last call takes effect.
Priority of status code checking and exception suppression
Even if EnsureSuccessStatusCode() has been configured, suppressed exceptions still return null and will not trigger the status code checking logic.
Priority of exception suppression
The exception suppression feature has a higher priority than status code checking. If both status code checking and exception suppression are enabled, exception suppression takes effect first.
Request interceptors remain available
If the exception is captured via SetOnRequestFailed(ex, res) or other request handling mechanisms, the interceptor or callback method will still be called even if the exception is suppressed.
Recommendations on selecting exception types
You should carefully select the exception types to suppress based on the specific business scenario, to avoid masking potential problems by over-suppressing exceptions.
Automatically output suppression logs
When an exception is successfully suppressed, the framework automatically outputs a Warning-level log (for example "An exception occurred but was suppressed by SuppressExceptionPipelineHandler."), making it easier to troubleshoot problems.