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

Should logger fail if there's an error #9

Open
nofun97 opened this issue Jan 29, 2020 · 6 comments
Open

Should logger fail if there's an error #9

nofun97 opened this issue Jan 29, 2020 · 6 comments

Comments

@nofun97
Copy link
Member

nofun97 commented Jan 29, 2020

In https://github.com/anz-bank/pkg/blob/master/log/util.go#L17 the library will panic if logger isn't created yet. Should the library fail or not?

@nofun97 nofun97 changed the title Should logger fail if there's no logger created yet Should logger fail if there's error Jan 30, 2020
@nofun97 nofun97 changed the title Should logger fail if there's error Should logger fail if there's an error Jan 30, 2020
@nofun97
Copy link
Member Author

nofun97 commented Feb 4, 2020

I don't think it should return error but failing silently can be problematic. Maybe it should just log a warning if there's no logger. Or should it add a standard logger when there's no logger?

@nofun97
Copy link
Member Author

nofun97 commented Feb 4, 2020

Currently, the library will panic when trying to log or get a logger and when it fails to apply a configuration. https://github.com/anz-bank/pkg/blob/master/log/util.go#L23-L56

@jamesrom
Copy link

jamesrom commented Feb 4, 2020

I am in favour of not panicking if the logger is not on the context. A default logger could be used when one is missing on the context.

This will allow code to transition to using this package a bit easier. Thinking tactically, for example, if there's some crucial logging that needs to be done but passing context all the way down into to that line of code would require a large refactoring.

Defaults should cover most use cases, and not write a warnings. However, if it's important to let the developer know they should configure a logger manually, I would be in favour of adding a special value to the log line produced, something like unconfigured_logger=true or context=default_logger.

@nofun97
Copy link
Member Author

nofun97 commented Feb 4, 2020

Okay, what about during applying a configuration to a logger? We're trying to let user make their own configuration, to handle that, we have the function func Apply(logger Logger) error and currently if would panic if Apply fails.

@anzdaddy
Copy link
Member

anzdaddy commented Feb 4, 2020

Agreed, logging should generally not fail. Serving traffic is more important that getting the logs. Monitoring can generate alerts when there's a step change in logging volume. So…

  1. Let's add a default logger.
  2. Follow the same principle for Apply: logging functions shouldn't impact traffic.

@anz-rfc
Copy link

anz-rfc commented Oct 7, 2020

If this library automagically creates and starts using a default-configuration-logger if there isnt a logger in a context, i think it needs offer an API that lets the programmer look inside a context to see if it contains a logger or not. Is there already a way of doing that? I can see there is a func From(ctx context.Context) Logger , but it creates a default logger and doesnt give the caller a way to tell which logger they got -- one that was in the input ctx or a new one.

e.g. in a variety of situations when i am trying to configure and wire my app together properly, i want to make sure i am using my special logger instance with custom configuration. if i dont have that exact logger in a context i want to be able to detect it and fail as it indicates a programming error.

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

4 participants