When calling Entry.log a panic inside some of the
locking blocks could cause the whole logger to deadlock.
One of the ways this could happen is for a hook to cause
a panic, when this happens the lock is never unlocked and
the library deadlocks, causing the code that is calling
it to deadlock as well.
This changes how locking happens with unlocks at defer
blocks so even if a panic happens somewhere along the log
call the library will still unlock and continue to function.
- added benchmarks, and assertions for timeliness
- replaced regex usage in package-name handling with a straight
comparison to a cached value
- log the fullly-qualified method name, to remove ambiguity
eg: github.com/fflintstone/yabba.dabba.doo
- clean up possibly-unsafe assumptions about using the standard logger,
remove global lookup function to enforce safe usage
- empty string as marker for failure to discover calling function
- tighten up logger usage - don't rely on std logger internally
Also fix ordering of expected/got in logrus_test.go to ensure correct
output form test failures.
If log.SetReportMethod(true) then method=PACKAGE.FUNCTION will be added
as a field to log lines.
eg: time="2016-11-25T19:04:43-08:00" level=info method=main msg="log
testing"
TODO: documentation, examples
While GO offers the ability to recover from panic there is no way to intercept an os.Exit event. To allow graceful shutdown and clean-up or programs which use Logrus to Fatal out I've borrowed ideas from the `atexit` package and enhanced Logrus.
Usage:
* When setting up the logger one call `RegisterExitHandler( func() {...} )` to add a handler that will be invoked for any `Fatal` call to the logger.
`WithField` and `WithFields` right now doesn't chain properly. Meaning
that if you do something like:
localLog := logger.WithField("tag", "value")
localLog.WithField("v1", "value").Info("message1")
localLog.Info("message2")
The `v1` will be carried over to `message2`.
With this patch, each WithField/WithFields call are isolated.
Michael Haines