-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
add helping log when trying to access an entity that does not exist #1712
Conversation
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.
This is useful and your implementation seems sensible.
let location = match self.entities.get(entity) { | ||
Ok(entity_location) => entity_location, | ||
Err(err) => { | ||
warn!("Error getting entity {:?}: {:?}", entity, err,); |
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.
warn!("Error getting entity {:?}: {:?}", entity, err,); | |
warn!("Error getting entity {:?}: {:?}", entity, err); |
I think this trailing comma is here by mistake?
let location = match self.entities.get(entity) { | ||
Ok(entity_location) => entity_location, | ||
Err(err) => { | ||
warn!("Error getting entity {:?}: {:?}", entity, err,); |
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 warn!
is a too strong log level. The user may very well just not care about if the entity exists or not. I think it would be better to return Result<EntityRef, GetEntityError>
where GetEntityError
has a Debug
implementation that shows all this information.
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 agree. This method feels too "low level" and could be called in too many different situations to call this case a warning / make it unrecoverable. I'd prefer to preserve the simplicity of the Option
return type (like std
's collection types) if possible, but if we really need to expose multiple "failure" states, it probably makes sense to just return an error here.
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... can't remember why I wanted a warn here :(
I could weakly argue that the user should not ignore this, but the Option
already achieve that.
For the error reason, I think knowing it can help the user debug issues looking at the log but is not very useful from the code. Should I change the log to info or debug?
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 honestly don't want to log at all here. If some subset of users need to care about the various reasons an entity might not exist, then imo we need to return a Result here.
Noticed in #1707
This adds a warn log when accessing an entity that doesn't exist, and the reason (doesn't exist yet or already despawned)