Introduce more specific exceptions, like NotFound, AlreadyExists, BadRequest, PermissionDenied, InternalError, and others

[nfx]

See implementations in other SDKs:

• Go: Introduce more specific exceptions, like errors.Is(err, databricks.ErrNotFound), errors.Is(err, databricks.ErrAlreadyExists), errors.Is(err, databricks.ErrBadRequest), errors.Is(err, databricks.ErrPermissionDenied), errors.Is(err, databricks.ErrInternal), and others databricks-sdk-go#682
• Python: Introduce more specific exceptions, like NotFound, AlreadyExists, BadRequest, PermissionDenied, InternalError, and others databricks-sdk-py#376

[mgyucht]

Largely looks good to me, but I think there are a couple issues with ordering in ErrorMapper and with error codes being dropped for status code-based errors.

[mgyucht]

This case isn't used yet, but I suspect you may want to use it if you follow my comments in AbstractErrorMapper.java.

[mgyucht]

I think this is in the wrong order: we should check for specific error code first and then fall back to status code.

[mgyucht]

I think this could cause some confusing behavior for old clients when new error codes are introduced. The error code provided in the API response is not explicitly propagated to these exception types. I think you might need two "rule" interfaces: one for ErrorCode-based exceptions (with well-known error codes, so only need parameters for message and details) and one for StatusCode-based exceptions (with dynamic error-codes, so you need an extra parameter for the error code).

[mgyucht]

This test will fail once I merge the follow-up change (equivalent of databricks/databricks-sdk-py@45a356c)

[tanmay-db]

Noted, cc: @edwardfeng-db as current oncall (nightly would fail but it's expected).

[edwardfeng-db]

ack, thanks. But do we expect a fix?

[mgyucht]

I will fix it in that PR, no worries.l

[tanmay-db]

We should store them and return at the end because in future we might need to use both statusCodeMapping and errorCodeMapping, with early return we give precedence to errorCodeMapping.

[mgyucht]

Error codes always take precedence over status codes. The same status code could be used to represent different error codes. Because of this, we don't need to store status code there.

[tanmay-db]

Noted, cc: @edwardfeng-db as current oncall (nightly would fail but it's expected).