Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix logging #1

Open
Habbie opened this issue Feb 24, 2019 · 0 comments
Open

fix logging #1

Habbie opened this issue Feb 24, 2019 · 0 comments

Comments

@Habbie
Copy link
Member

Habbie commented Feb 24, 2019

Right now the package just writes to stdout, which is terrible. It is also super verbose.

The caller should decide where logging goes, and how much of it.

Some help from #go-nuts:

20:28Z <Habbie> what's the right way to add 'debug logging' to a library? the library doesn't know what logging lib, if any, the app is using
20:29Z <X> dependency injection
20:29Z <Habbie> X, do you have a few more words on that for me?
20:29Z <X> golang dependency injection interface
20:30Z <Habbie> ah yes
20:30Z <X> I'd also avoid logging to a constant stderr/stdout if this is a package; let the user decide where the logs end up (have them supply a log function or at least an io.Writer to log to)
20:31Z <Habbie> it would be a package, yes; and indeed i don't want to log to stdout/stderr unless the consumer wanted me to
20:31Z <Habbie> but in other projects i saw log libs being mixed and it was a mess
20:31Z <X> be careful with races (just printing is not thread-safe, the funcs/meths in the log package are)
20:31Z <Habbie> 'have them supply a log function' is roughly what you meant by dependency injection?
20:31Z <X> I'd stay away from depending on a specific logger package, indeed.
20:31Z <X> accept a simple interface.
20:32Z <Habbie> that's how i understood it
20:32Z <Habbie> perfect, thanks
20:32Z <Habbie> still getting my head around what's common and useful to do in Go
20:36Z <X> Habbie: I tend to do it something like this. [see next paste]
20:36Z <X> perhaps there's a better way.
20:41Z <Habbie> X, thanks, will digest that in a bit :)
20:43Z <y> Habbie: information from debug.Stack() works well for me as I am able to see the line numbers in my applications log files & relate to source code on my end
20:43Z <Habbie> y, ah thanks, that's what i always do in Lua indeed
20:44Z <y> Compared to the thread-unsafe nonsense that C++ stack traces were when I tried this method, I found golangs to work very reliably
package main

import "log"

func main() {
	withoutLogging := NewMyPackageType()
	withoutLogging.DoStuff()

	withLogging := NewMyPackageType(
		WithDebugLogf(log.Printf),
	)
	withLogging.DoStuff()
}

type MyPackageType struct {
	debugLogf func(format string, v ...interface{})
}

func NewMyPackageType(opts ...func(*MyPackageType)) *MyPackageType {
	t := &MyPackageType{
		debugLogf: func(string, ...interface{}) {},
	}

	for _, o := range opts {
		o(t)
	}

	return t
}

func (t *MyPackageType) DoStuff() {
	t.debugLogf("look I'm %s logging", "debug")
}

func WithDebugLogf(f func(format string, v ...interface{})) func(*MyPackageType) {
	return func(t *MyPackageType) {
		t.debugLogf = f
	}
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant