Skip to content

Let user decide what to do if logger is not in context#175

Closed
ghost wants to merge 1 commit into
masterfrom
unknown repository
Closed

Let user decide what to do if logger is not in context#175
ghost wants to merge 1 commit into
masterfrom
unknown repository

Conversation

@ghost

@ghost ghost commented Aug 8, 2019

Copy link
Copy Markdown

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.

Comment thread ctx.go Outdated
@smyrman

smyrman commented Aug 9, 2019

Copy link
Copy Markdown

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.

@ghost

ghost commented Aug 13, 2019

Copy link
Copy Markdown
Author

@smyrman That sounds like a good idea, I'll try it and update README if it turns out to be a solution.
UPDATE:
Ok, so since disabledLogger is package scope I basically renamed it to DefaultLogger so that user could control its behavior.

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.
@ghost ghost closed this Aug 13, 2019
@ghost ghost deleted the feature/strict-mode branch August 13, 2019 06:44
@gitarte

gitarte commented Aug 13, 2019

Copy link
Copy Markdown

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.

Failing a program when logger is not set may be crucial in some fields:

  • banking
  • military
  • automotive

In general there where lack of log may cause puting you in jail. Please reconcider merging this pull request.

@Jarema

Jarema commented Aug 13, 2019

Copy link
Copy Markdown

@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.

@smyrman

smyrman commented Aug 13, 2019

Copy link
Copy Markdown

@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 nil.

@smyrman

smyrman commented Aug 13, 2019

Copy link
Copy Markdown

See #177

This pull request was closed.
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

Successfully merging this pull request may close these issues.

4 participants