Error-handling hygiene: err["error"] KeyError, no raise-from, bare except, message-less exceptions

[martinkersner]

Summary

Several error-handling paths are non-idiomatic and one is a latent crash-in-the-error-path.

Issues

1. err["error"] KeyError risk — datamaxi/_dispatch.py:78: on a 4xx the handler does err["error"]. If the backend body omits "error", the handler itself raises KeyError, masking the real HTTP error. Use err.get("error", text).

2. No exception chaining — _dispatch.py:73-74: except JSONDecodeError: raise ClientError(...) drops the cause. Use raise ... from None (or from exc) intentionally.

3. Bare except: — datamaxi/lib/utils.py:48 (check_at_least_one_set_parameters, silenced with # noqa: E722). Narrow to except ParameterRequiredError.

4. Custom exceptions carry no message — datamaxi/error.py:5-20: ClientError / ServerError store attributes but never call super().__init__(...), so str(err) is empty/uninformative. Pass a formatted message up.

Impact

#1 can turn a normal API error into a confusing KeyError; the rest hurt debuggability and lint cleanliness.

---

Surfaced during a pythonic-idiom review of the SDK.