Hi Ashok, thanks for the proposal. Today the client implicitly maps NotFoundException to NoSuchTableException. I agree we should preserve the distinction on the client side so callers of these clients can handle these cases differently.
Yufei On Tue, Sep 9, 2025 at 8:22 AM Ryan Blue <[email protected]> wrote: > NoSuchTableException is the correct exception to use when a table is not > in the catalog. NotFoundException is intended for cases where an expected > file is missing (see the description > <https://github.com/apache/iceberg/blob/main/api/src/main/java/org/apache/iceberg/exceptions/NotFoundException.java#L23C5-L23C73>). > That is, if the table exists in the catalog but is corrupt because the > metadata file is missing, then it may be NotFoundException. That's not the > same as the table doesn't exist, so I'm not sure that we want to > convert over to NoSuchTableException that might hide the error. And we > definitely don't want to convert NoSuchTableException to NotFoundException. > That would cause a lot of headaches. > > On Tue, Sep 9, 2025 at 5:44 AM Ashok Krishna <[email protected]> > wrote: > >> Hi Team, >> I would like to bring up an issue I've identified regarding exception >> handling in the Iceberg REST Catalog. >> >> Currently, if a table exists but its metadata file is missing, the *Iceberg >> REST Catalog* returns a *NoSuchTableException*. I believe this behavior >> is inconsistent with other catalogs, such as Glue and JDBC, which correctly >> return a *NotFoundException* in this scenario. >> >> This inconsistency can lead to confusion and make client-side error >> handling more complex. To address this, I've created a pull request that >> changes the REST Catalog's behavior to align with the other catalogs, >> ensuring a consistent *NotFoundException* is thrown when a table's >> metadata file is missing. >> >> You can find the proposed change here: >> https://github.com/apache/iceberg/pull/13143 >> >> Could you review and let me know if there are any questions/concerns? >> >> >> Thanks, >> Ashok >> >
