Improve code quality by removing a potential nil panic

[chengpeng-wang]

Dear developers,

In the Logger.check function, the result of log.core.Check(ent, nil) is assigned to ce and later used in a switch block that may call methods on ce (e.g., ce.After(...)) without ensuring it is non-nil. This can lead to a nil pointer dereference panic if the implementation of Check returns nil.

Although the current code checks whether ce != nil holds at line 361 (Link), the check occurs too late. I think the original purpose of introducing the !willWrite check should be to avoid the nil pointer dereference panic, but it was mistakenly placed in the wrong location in the program.

We have provided a patch for your reference. With this patch, the code would be more reliable than the original one. We hope our effort helps improve your code quality.

[abhinav]

This is by design.
There's no risk of nil panic here as ce.After is nil safe.
It creates a ce if there wasn't one there before.

zap/zapcore/entry.go

Lines 301 to 305 in 6d48253

	func (ce *CheckedEntry) After(ent Entry, hook CheckWriteHook) *CheckedEntry {
	if ce == nil {
	ce = getCheckedEntry()
	ce.Entry = ent
	}

This PR would change the behavior, returning nil instead of non-nil in these cases, dropping the panic/fatal/dpanic post-logging behaviors.

There are plenty of unit tests that catch this. Please run go test, and you'll see that this change breaks those behaviors.