Obscure error message on table name clash with a namespace in NoSQL Persistence

[dimas-b]

Describe the bug

When an attempt to create a table clashes with a pre-existing namespace (same name as the new table) and Polaris uses NoSQL persistence, the resulting error message is not user-friendly.

To Reproduce

1. Run Polaris with NoSQL persistence, e.g. java -Dpolaris.persistence.type=nosql -Dpolaris.persistence.nosql.backend=InMemory -Dpolaris.persistence.auto-bootstrap-types=nosql -jar runtime/server/build/quarkus-app/quarkus-run.jar
2. Create a catalog
3. Run Spark
4. In Spark:

use polaris;
create namespace ns;
create namespace ns.n2;
create table ns.n2 (n string);
[... error message here ...]

Actual Behavior

spark-sql ()> create table ns.n2 (n string);
26/04/01 17:54:38 ERROR SparkSQLDriver: Failed in [create table ns.n2 (n string)]
java.lang.IllegalArgumentException: Mismatch between persisted object type 'ns-l' (interface org.apache.polaris.persistence.nosql.coretypes.content.LocalNamespaceObj) and deserialized interface org.apache.polaris.persistence.nosql.coretypes.content.IcebergTableObj. The object ID 143836371406233600 is possibly already used by another object. If the deserialized type is a GenericObj, ensure that the artifact providing the corresponding ObjType implementation is present and is present in META-INF/services/org.apache.polaris.persistence.nosql.api.obj.ObjType
	at org.apache.iceberg.rest.ErrorHandlers$DefaultErrorHandler.accept(ErrorHandlers.java:232)
	at org.apache.iceberg.rest.ErrorHandlers$TableErrorHandler.accept(ErrorHandlers.java:124)
	at org.apache.iceberg.rest.ErrorHandlers$TableErrorHandler.accept(ErrorHandlers.java:108)
[...]

Expected Behavior

More user-friendly error message.

Additional context

Commit 2acf472

System information

No response

[Subham-KRLX]

@dimas-b I would like to work on this issue and submit a PR to fix it my plan is to add a check before table creation to detect if a namespace with the same name already exists and return a clear user friendly error message instead of the current obscure exception. Could you please assign this issue to me.

[dimas-b]

@Subham-KRLX : that sounds like a good plan. I was also thinking to address it in a persistence-neutral way. Please feel free to go ahead and make a PR.