Exceptions need more granular types

[james-whiteside]

Problem to Solve

Exceptions need more granular types.

E.g. I run the query match $t sub {my_type}; with a user-defined string my_type. If I get TypeDBClientException, is it because the type my_type does not exist in the database, or because the string my_type contains illegal query characters? I should be able to try/except individually for these cases. Other similar cases exist, where currently most errors seem to just be TypeDBClientExceptions.

Current Workaround

I could process the exception message to get more information about the error as they seem to already be loosely typed. With reference to the above example, compare:

typedb.common.exception.TypeDBClientException: [TYR03] Invalid Type Read: The type 'relations' does not exist.
typedb.common.exception.TypeDBClientException: [TQL03] TypeQL Error: There is a syntax error at line 1:

but this is both inelegant and has potential for unintended behaviour.

Proposed Solution

Make exceptions more strongly typed.

[alexjpwalker]

Proposal to extend our gRPC error architecture (which would fix this issue):

• Build flexible client-server error architecture to replace gRPC error states typedb#6146

Closing as entirely covered by that!