-
Notifications
You must be signed in to change notification settings - Fork 199
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 log lines to help debug NPE in resolveLocationForPath #585
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -554,14 +554,27 @@ private String resolveNamespaceLocation(Namespace namespace, Map<String, String> | |
.map( | ||
entity -> { | ||
if (entity.getType().equals(PolarisEntityType.CATALOG)) { | ||
return CatalogEntity.of(entity).getDefaultBaseLocation(); | ||
CatalogEntity catEntity = CatalogEntity.of(entity); | ||
String catalogDefaultBaseLocation = catEntity.getDefaultBaseLocation(); | ||
flyrain marked this conversation as resolved.
Show resolved
Hide resolved
|
||
if (catalogDefaultBaseLocation == null) { | ||
LOGGER.warn( | ||
"Tried to resolve location with catalog with null default base location. Catalog = {}", | ||
catEntity); | ||
} | ||
return catalogDefaultBaseLocation; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should a catalog ever have a null base location? This feels like a case for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not too familiar and don't know if this should ever not happen but sounds good to use
to get the diagnostic services to call checkNotNull though so please check if it's safe to do this or if we should be worried about NPEs.. It seems like elsewhere in the code we're assuming there aren't nulls when calling such methods. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think there was previously a bug where we were setting the base location to null; it could conceivably happen again. Agreed that this should be in
Yes, I think we lean a little too heavily on the non-functional @nonnull annotation unfortunately. Adding more lightweight checks for this around is definitely a good idea |
||
} else { | ||
String baseLocation = | ||
entity.getPropertiesAsMap().get(PolarisEntityConstants.ENTITY_BASE_LOCATION); | ||
if (baseLocation != null) { | ||
return baseLocation; | ||
} else { | ||
return entity.getName(); | ||
String entityName = entity.getName(); | ||
if (entityName == null) { | ||
LOGGER.warn( | ||
"Tried to resolve location with entity without base location or name. entity = {}", | ||
entity); | ||
} | ||
return entityName; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same here - there should never be an entity without a name. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See #585 (comment) |
||
} | ||
} | ||
}) | ||
|
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.
Refactor suggestion: would the code be cleaner if we put these into a new method like
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.
sounds good. Moved this logic to
baseLocation
helper!