Repository navigation
Strongly Typed AthenaError #35
Description
This particular assertion kinda gives me an idea that this test is too tightly coupled to exactly what the error handling logic will do re: strings.
Wonder if it's better to make more, strongly typed, errors that inherit from AthenaError like AthenaAffiliateAuthError or something. Can do that in a way that's not breaking to previous version's code too since they'll except AthenaError.
Originally posted by @snus-kin in #27 (comment)
Activity
snus-kin commentedon Sep 24, 2025
Specifically the issue here I think is revealed that we're asserting on messages of exceptions instead of the types which makes it hard(er) to reason about why exactly an exception was thrown.
Broadly we should make the error handling API of this client library as expressive as possible given the range of responses we get back from the Athena API.
We should be able to implement sub-classes to
AthenaErrorwithout much issue re: compat because we know that anyone catching them will catch the super-class anyway.