I'd really like to be able to use this library to log HTTP requests. In that case, the resulting status code is important enough that it needs to be formatted into the message.
Instead of:
[INF] HTTP GET for /download completed in 456.7 ms
I want:
[INF] HTTP GET for /download completed with 200 in 456.7 ms
200 here would be called StatusCode, collected by Complete().
I don't have a great proposal for how to work this into the API, but I think that it's important to build it in such a way that the message template is still fixed at the time the operation is begun, not when completed.
I.e. a failure caused by an uncaught exception might look like:
[WRN] HTTP GET for /download abandoned with null in 456.7 ms
Properly handling the failure should be able to produce:
[ERR] HTTP GET for /download completed with 500 in 456.7 ms
I think that if this can be accommodated without compromising the core principles of this library it'd be a great addition.
I'd really like to be able to use this library to log HTTP requests. In that case, the resulting status code is important enough that it needs to be formatted into the message.
Instead of:
I want:
200here would be calledStatusCode, collected byComplete().I don't have a great proposal for how to work this into the API, but I think that it's important to build it in such a way that the message template is still fixed at the time the operation is begun, not when completed.
I.e. a failure caused by an uncaught exception might look like:
Properly handling the failure should be able to produce:
I think that if this can be accommodated without compromising the core principles of this library it'd be a great addition.