This code illustrates the blog article Better timeout handling with HttpClient.
Key features:
- control the timeout per request, rather than globally for all requests
- throw a more sensible exception (
TimeoutException
) when a timeout occurs, instead of the usualOperationCanceledException
It is state in terms of the request, but read what Microsoft wrote (emphasized): "Use one of the following approaches to share per-request state WITH message handlers"
My previous statement: "A request timeout is not really a request state that needs to be associated with the message handlers"
I wasn't disputing whether it is "state" or not -- I was explaining that it isn't something that needs to be shared among the message handlers, which is the context for the suggestions listed. My inheritance approach also doesn't inherently become obsolete with the change in .NET 5.0. To get a timeout you don't necessarily need to share the timeout state across message handlers though, and my own implementation allows it to be somewhat separate.
edit: Perhaps there is just a discrepancy between how we're viewing the word "share" as you hinted at in your prior comment.
I was referencing this to demonstrate how my solution is future proof based on these changes.
This is all fair, but in the context of the requirement for sharing state between message handlers, a timeout doesn't need to as I mentioned earlier. (i.e. The underlying solution here is based on exceptions.)
There are hints towards the dislike of the loose typing with the initial property as well. In my case that isn't an issue at all with extending the class. My overall view is that this should be something that you can apply to any request by default. (Additionally, unless you have a really unique key name, an external implementer runs the risk of accidentally overwriting that key with a new value. I think the extensibility in my case helps mitigate a lot of problems like this for a universal approach.)
I'm open to any pitfalls though if you can think of something that I'm missing. (To clarify, I'm also not saying to avoid Properties/Options entirely. I use it for my serialization/deserialization and authentication pipelines.)