-
-
Notifications
You must be signed in to change notification settings - Fork 256
Fix: Use dartLogger as default in debug mode #413
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
Conversation
PR looks good but it's failing due to pod install, probably not related at all |
dart/lib/src/sentry.dart
Outdated
// user visible between Sentry's initialization and the invocation of the | ||
// options configuration callback. | ||
if (options.debug == false && options.logger == dartLogger) { | ||
options.logger = noOpLogger; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about doing this on the setter of logger
and of debug
?
Can we call it diagnosticLogger? If we're bumping a major ideally.
We have some docs on it for .NET for example:
https://docs.sentry.io/platforms/dotnet/configuration/diagnostic-logger/
The goal is to "relate" to the level:
https://docs.sentry.io/platforms/flutter/configuration/options/#diagnostic-level
And to disambiguate with any sort of logging integration we have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dart already has a DiagnosticLogger
, when you set a logger
it already wraps up to a DiagnosticLogger
that takes into consideration the diagnosticLevel
field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what Bruno meant is to rename the property to diagnosticLogger
in order to make its purpose more clear.
The logger is also just a function in the Dart/Flutter SDK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we cant rename now, this would require a major bump, every call to options.logger(params)
would change.
what @bruno-garcia meant is, instead of doing such if
condition to set a dartLogger
or noOpLogger
could be encapsulated within a setter.
so options.debug = true (means setting dartLogger
)
options.debug = false (means setting noOpLogger
).
I like that.
the same could happen if one sets options.logger = function(), this would automatically set options.debug = true
and options.logger = null would set options.debug = false
, so such conditions are not across the SDK but only setting it enabled or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what @bruno-garcia meant is, instead of doing such if condition to set a dartLogger or noOpLogger could be encapsulated within a setter.
Yes! ;)
the same could happen if one sets options.logger = function(), this would automatically set options.debug = true and options.logger = null would set options.debug = false
I wouldn't go this far though. One might change the logger type in an integration but not really be turning debug mode on or off.
I think what Bruno meant is to rename the property to diagnosticLogger in order to make its purpose more clear.
Also this. What about we do this on a next major release? If so, is there a Discussion that keeps tracks of stuff we want to add to the next major?
so options.debug = true (means setting dartLogger)
options.debug = false (means setting noOpLogger).
I'm not sure I would override the logger instance when someone sets false
since next time you set it to true
you no longer know what instance was set by the user before.
In .NET it's nullable, so that the call to the logger doesn't happen at all and hence no string concat or anything happens in order to invoke the logger. With NoOp you're calling things so any overhead to prepare the log entry is paid even though the logger doesn't do anything. That's just an optimization though, not saying it's something that we need to align. For really expensive operations we can always check: logger.isEnabled(level)
before actually calling the logger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If so, is there a Discussion that keeps tracks of stuff we want to add to the next major?
Now there is: #419
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With NoOp you're calling things so any overhead to prepare the log entry is paid even though the logger doesn't do anything. That's just an optimization though, not saying it's something that we need to align. For really expensive operations we can always check: logger.isEnabled(level) before actually calling the logger.
I feel like a callback for the logger would be more ergonomic than a null check.
For example:
logger.log(level, () => 'this callback gets invoked from the logger')
Than we would not need to have the actual code riddled with ifs and what not and also the logging is only computed when needen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an allocation for the callback though. So between the callback and NoOp I'd surely go with the latter.
So it's not clear to me how I should proceed here. @marandaneto @bruno-garcia |
let's discuss today in our call |
…bug-mode # Conflicts: # dart/lib/src/sentry_options.dart
Sorry I missed the call. Let me know if my input is needed, otherwise |
Should I set |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
📜 Description
In debug mode Sentry now uses the dartLogger (which writes to console) as a logger.
The first thing the SDK does is to create an instance if SentryOptions, so the logical place to put this logic is SentryOptions.
This change also works for Sentry and Sentry Flutter.
💡 Motivation and Context
#384
💚 How did you test it?
I've written new tests.
📝 Checklist
🔮 Next steps