I looked at the long list of proposals to improve error handling in go but
I have not seen the one I am describing below. If I missed a similar , can
you pls direct me to where I can find it. If not what do you think of this
approach.
This involves introducing a new keyword "orelse" that is a
"The confusion may come from the fact that a list of forbidden built-in
operations is immediately followed by a list of (mostly) allowed operations
that illustrate the original rule?"
You hit the nail on the head.
I don't have much faith in me as programmer, so I ask about any such issue
that is b
There is a slight problem here that the requestWrapper would have to be
implemented very deep through many layers of library. For example there
might be a data structure passed down a chain of handlers with a custom
argument structure, which contains a http.Request per some old design
decisions
We don't plan on exposing the commonLogger implementation, but you can
write your own handler to get the exact format you want.
See github.com/jba/slog/handlers for some existing code.
See https://github.com/golang/example/tree/master/slog-handler-guide for a
guide to writing a slog handler.
On
I would write a type that wraps the request and implements LogValuer. Then
you would log the request as
logger.Debug("req", "r", requestWrapper{r})
On Thursday, July 27, 2023 at 10:01:27 AM UTC-4 Jens-Uwe Mager wrote:
> I am trying to convert some older code to slog and I am running into t
