apache/iceberg · error · UnsupportedOperationException
Retrieving a view's location is not supported
Error message
Retrieving a view's location is not supported
What it means
View.location() is a default method on the View interface that intentionally throws UnsupportedOperationException. Iceberg uses interface defaults so that concrete catalog implementations (e.g. REST-backed views) only override the methods they support. Hitting this means the concrete View implementation in use does not expose the view's base location.
Source
Thrown at api/src/main/java/org/apache/iceberg/view/View.java:88
*
* @return a list of {@link ViewHistoryEntry}
*/
List<ViewHistoryEntry> history();
/**
* Return a map of string properties for this view.
*
* @return this view's properties map
*/
Map<String, String> properties();
/**
* Return the view's base location.
*
* @return this view's location
*/
default String location() {
throw new UnsupportedOperationException("Retrieving a view's location is not supported");
}
/**
* Create a new {@link UpdateViewProperties} to update view properties.
*
* @return a new {@link UpdateViewProperties}
*/
UpdateViewProperties updateProperties();
/**
* Create a new {@link ReplaceViewVersion} to replace the view's current version.
*
* @return a new {@link ReplaceViewVersion}
*/
default ReplaceViewVersion replaceVersion() {
throw new UnsupportedOperationException("Replacing a view's version is not supported");
}
View on GitHub (pinned to 86d9c8fc54)
Solutions
- Use a catalog/View implementation that overrides location() (e.g. one built on BaseView or the standard metadata-backed view).
- If you only need the location to create/update the view, use SQL extensions (CREATE VIEW ... LOCATION) or catalog-level APIs instead of reading location() from the returned object.
- In tests, replace stub Views with real implementations that override location().
Example fix
// before
String loc = view.location();
// after
if (view instanceof BaseView) {
String loc = ((BaseView) view).location();
} else {
// fall back to catalog metadata or skip location-dependent logic
} Defensive patterns
Strategy: type-guard
Validate before calling
boolean supportsLocation = !(view.getClass().getSimpleName().equals("View") && isDefaultMethod(view, "location")); Type guard
static boolean supportsLocation(View v) { return v instanceof BaseView; } Try / catch
try { return view.location(); } catch (UnsupportedOperationException e) { return null; } Prevention
- Load views from catalogs returning BaseView-backed implementations
- Avoid stubbing the View interface in tests without overriding used methods
When it happens
Trigger: Calling view.location() on a View object returned by a catalog (e.g. loadView) whose implementation does not override location().
Common situations: Code written against a mock or custom View implementation in tests; catalogs that return a minimal View wrapper; code assuming all View implementations behave like BaseView.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- Replacing a view's version is not supported
- Updating a view's location is not supported
- Retrieving a view's uuid is not supported
- Resolving a sql with a given dialect is not supported
- %s does not implement deleteFile
AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12).
Data as JSON: /api/errors/21509786185d5fe2.
Report an issue: GitHub.