Conversation
|
Failing a program because a logger is not set in context seams like a bad design to me. Perhaps you could configure a setable defaultLogger to be used when a logger isn't found in context, and return that instead of the disabled logger. Then you can actually avoid loosing logs without updating all your code to handle the logger == nil case. |
|
@smyrman That sounds like a good idea, I'll try it and update README if it turns out to be a solution. |
As for now disabledLogger is being returned if user tries to get logger from context.Context. Such a behaviour may be beneficial, but in other cases it will be harmful. Giving user an option to return nil and fail with nil pointer error may prevent logs loss.
Failing a program when logger is not set may be crucial in some fields:
In general there where lack of log may cause puting you in jail. Please reconcider merging this pull request. |
|
@smyrman to just put my few thoughts: in some mission critical scenarios and industries, missing log, or having incomplete log may break the audit path, which might lead to really bad (even legal) consequences. So yes - not having proper logs is in some cases totally valid reason to fail the application. |
|
@Jarema and @gitarte, I don't know how commonly zerolog or even Go as a language is used in any of the situations you describe. That said, if you can set a default logger instead of setting a strict mode, it allows for more use-cases, including yours. If you prefer your program to crash, nothing will stop you from setting a default logger that panics when used. E.g. set it to |
|
See #177 |
As for now disabledLogger is being returned if user tries to get logger from context.Context.
Such a behaviour may be beneficial, but in other cases it will be harmful.
Giving user an option to return nil and fail with nil pointer error may prevent logs loss.
This commit is not introducing any breaking change.