denominator icon indicating copy to clipboard operation
denominator copied to clipboard

Error handling - expected exceptions from cardinality violations

Open jdamick opened this issue 11 years ago • 1 comments

For the case where an add/remove on the ResourceRecordSetApi fails. The providers need a standard way to express errors that occur that are specific to a particular record type or provider record type.

As an example, in base DNS implementations you can only have 1 CNAME record at a particular label, www. in the case below.

Existing: www.denominator.io CNAME to www1 Then trying to add: www.denominator.io CNAME to www2 This should throw an exception such as:

TargetExistsException (which extends IllegalStateException)

Other implementations may allow this behavior through different provide specific extensions, round-robin answers, "pools", etc. - In this case there may be other errors that would occur, these should also throw TargetExistsException or IllegalStateException as appropriate.

jdamick avatar Mar 04 '13 19:03 jdamick

+1

As you mentioned, there are extensions that exist, and speaking for netflix, we use weighted record sets which violate normal expectations of CNAME. I'm not sure we will continue using these or not, but since they do exist, let's hesitate before enforcing client-side rules like how many values a CNAME can have. Your approach addresses this by suggesting in the case multiple CNAME values aren't supported on the server, the user should expect a TargetExistsException. Perhaps later, we may decide to expose metadata about what a server supports, but for now, I think your approach of just clarifying (and testing) which exception folks will receive is the best course.

codefromthecrypt avatar Mar 04 '13 22:03 codefromthecrypt