I don't think we make strict guarantees about the "type" field. The description from the spec is "Internal type definition of the error" and we generally use it to send the original exception type where we are mapping Iceberg exceptions (such as `NoSuchTableException`) into HTTP error codes (404).
It may be valuable to not send Java class names through "type" since we don't want to be Java-specific, but that is a different kind of change. If we were to use `BadRequestException`, we'd be losing information here because we would be using a more generic Java class rather than the specific error from the Java implementation, `ValidationException`. I think this is a good area to improve, but most likely by introducing another field that has a more specific error classification that is compatible across languages. Changing this Java class for a more generic one doesn't seem to gain much and I'd probably leave it alone. On Wed, Jan 21, 2026 at 10:53 AM Alex Stephen via dev < [email protected]> wrote: > Hello, > > Certain validation errors (example: sort orders referencing an invalid > field <https://github.com/apache/iceberg-python/pull/2937>) will cause > the iceberg-rest-fixture to throw the following 400 error. > > "error": { > "message": "Cannot find source column for sort field: identity(9999) > ASC NULLS FIRST", > "type": "ValidationException", > "code": 400, > } > > ValidationException isn't currently a recognized exception type in the > spec. What should the expected behavior be here? > > I'd personally expect that we would return: > > "error": { > "message": "Malformed request: Cannot find source column for sort > field: identity(9999) ASC NULLS FIRST", > "type": "*BadRequestException*", > "code": 400, > } > > This would conform with how we handle HTTP error code 400. > > Please let me know your thoughts. > > -- Alex Stephen >
