Change set_logger to panic on error #146
Labels
No labels
bug
duplicate
easy
enhancement
help wanted
invalid
question
rfc
structured-logging
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-rust-lang/log#146
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Almost all invocations of this want to panic (they're at the beginning of
main) and this may also be able to remove the closure argument (according to @sfackler).We should rename the current API to
try_set_loggerfor suitable use during tests.I am working on this.
The same thing needs to happen for
env_logger::init. There would be atry_initsuitable for tests.Can you guide me a bit how should I go about resolving this? I don't have much experience with Rust, but would love to help.
@alisha17 sure yeah! So right now the
set_loggerAPI is a global registration point for all loggers. As a result you can't really call it twice because the first logger is already registered. For that reason it currently returns aResultindicating "your logger was installed" or "no, some other logger was installed first and you lost the race".This issue, however, is that 100% of the time if you're initializing logging as part of
fn mainyou want unwrap the result! In that sense we should just bake in theunwrap-related panic to the function itself. So we'll want to change the signature ofset_loggerto return nothing. Now at the same time, however,fn mainisn't the only place that we initialize loggers. Tests frequently start all test cases withmy_logger::init()as we're not sure which test runs first. In that case we don't care who wins the race for registration (everyone's registering the same logger) so you'll typically seedrop(my_logger::init())to ignore the results. In that sense we need to preserve today's functionality with a function liketry_set_loggeralongsideset_loggerthat has the same semantics as today.So overall I think we'll be changing the
logcrate to look like:Does that sound right to you @sfackler?
Also what @dtolnay was mentioning is that most users rarely actually call the
set_loggerortry_set_loggerfunctions but rather a baked in initialization function in the logger they're using (e.g.env_logger::init). That just means we should, as part of this change, change theenv_loggercrate to have:Lemme know if you've still got any more questions though!
I guess the function set_logger already panics on error. It might have been fixed as a result of some other bug?
Although the renaming still remains to be done.
This set_logger function returns a SetLoggerError if there is an error. It does not panic.
But how can I remove the closure argument in the set_logger function without changing the aesthetics of the function?
@alisha17 it'd probably look liek:
Fixed.