-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Change Log
emitters to not emit event when block output is nil
#12000
Change Log
emitters to not emit event when block output is nil
#12000
Conversation
Could you please add a note about this to the API docs? |
Happy to see your first PR here, btw. 😄 |
src/log/log.cr
Outdated
# end | ||
# } | ||
# ``` | ||
def {{method}}(*, exception : Exception? = nil) |
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.
@straight-shoota Good call. I added an example here as well. The documentation here felt like it could be improved a bit by restructuring this macro iteration in order to get the name of the severity instead of just the number:
I didn't want to get too far into the weeds, I'm not sure if these out of scope changes are welcome in this pull request.
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.
do / end
would fit better. Multiline using { }
, while valid, is more so used for single line blocks. E.g. Log.warn { "Nothing will be logged" if false }
versus:
Log.warn do
if false
"Nothing will be logged"
end
end
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.
It's a stylistic debate. { }
is perfectly fine. It's often used to indicate that the block's output value matters.
# can be used. They expect a block that will evaluate to the message of the entry. | ||
# To log a message use the `#trace`, `#debug`, `#info`, `#notice`, `#warn`, | ||
# `#error`, and `#fatal` methods. They expect a block that will evaluate to the | ||
# message of the entry: |
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 switched this from:
"[methods] can be used" to "use the [methods]" which feels like it is more consistent with the technical writing tone I've observed elsewhere in the docs.
bb96092
to
60a0c2c
Compare
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.
👍
60a0c2c
to
dc97e15
Compare
Co-authored-by: Sijawusz Pur Rahnama <[email protected]>
dc97e15
to
bf5e952
Compare
Log
emitters to not emit event when block output is nil
Previous change crystal-lang#12000 skips logging when the given block returns `nil`, however it inadvertently also suppresses logging exceptions. Logging is now skipped only if both the given exception and the block result are `nil`.
Previous change crystal-lang#12000 skips logging when the given block returns `nil`, however it inadvertently also suppresses logging exceptions. Logging is now skipped only if both the given exception and the block result are `nil`.
Previous change crystal-lang#12000 skips logging when the given block returns `nil`, however it inadvertently also suppresses logging exceptions. Logging is now skipped only if both the given exception and the block result are `nil`.
Previous change crystal-lang#12000 skips logging when the given block returns `nil`, however it inadvertently also suppresses logging exceptions. Logging is now skipped only if both the given exception and the block result are `nil`.
Previous change crystal-lang#12000 skips logging when the given block returns `nil`, however it inadvertently also suppresses logging exceptions. Logging is now skipped only if both the given exception and the block result are `nil`.
fixes #11997