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

Allow Log to print undef values #2091

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

buralien
Copy link

@buralien buralien commented Aug 8, 2023

Print "undef" when an undef value is provided to Log, instead of throwing an error.

Fix issue where providing undef value to be logged results in an error.
@kraih
Copy link
Member

kraih commented Aug 8, 2023

What's the use case for this? And how much of a performance regression does it cause?

@buralien
Copy link
Author

buralien commented Aug 8, 2023

What's the use case for this?

In my experience, causing an error when an undef variable is provided to Log is not very user friendly and quite easy to achieve when communicating with external models.

my $val = $third_party_model->some_method();
$c->log->debug("GOT:", $val); # errors out if $val is undef

And how much of a performance regression does it cause?

I haven't found any performance tests in the suite. Both map and defined are core and are only evaluated in case the message is logged with high enough level. I assume that typically the Log methods are not called with very large array of args. What kind of test would be sufficient to answer this?

@jhthorsen
Copy link
Member

I don't think it's worth it. Doesn't seem to difficult to avoid it on the way in.

@guest20
Copy link

guest20 commented Sep 5, 2023

@jhthorsen every caller could map not defined ? "undef" : $_, @to_log to prevent the warning, but does that make web development fun?

@jhthorsen
Copy link
Member

@jhthorsen every caller could map not defined ? "undef" : $_, @to_log to prevent the warning, but does that make web development fun?

I'm not sure how often you really need that though. I made https://metacpan.org/pod/Mojolicious::Plugin::Logf for this reason (and some others), but I don't use it that often in my own projects, since it's often overkill imo.

@guest20
Copy link

guest20 commented Sep 6, 2023

@jhthorsen

Mojolicious::Plugin::Logf [is] often overkill imo.

Definitely.

However with Mojo::Log logging to STDERR, the same handle that perl warnings end up on, it can be a bit of a pita to consume log lines from an app where a call to the logger can cause warnings in a second format that come from within the logger.

Additionally a useful undef warning would refer to the call site of log, not in the guts of Mojo::Log::_short where the join happens. As it turns out, only way for a dev to fix a warning about an undef in _short is to submit a PR like this one...

@buralien
Copy link
Author

buralien commented Sep 8, 2023

I don't think it's worth it. Doesn't seem to difficult to avoid it on the way in.

In adition to the comments by guest20 (which I fully agree with), current implementation of Log does not even allow for clean subclassing to override the behavior in an app. Writing an additional if statement every time I want to log some value across an entire application, while not "difficult" is still quite cumbersome and makes for poor code readability.

I was not aware of Logf, so thanks for the tip. In case this PR is not approved, I'll use iot instead of patching Log in my CI pipeline (which is what I do right now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants