2.8, curious how we expect folks to communicate back?

[justinabrahms]

So I'm writing a test case for 2.8. I'm not entirely clear exactly what we're trying to accomplish with it.

So, ProviderEvaluation already has a mechanism for providing an error status. It sounds like the thing is saying "If things go bad, you can throw exceptions, but the exceptions must also somehow communicate a string code which the framework will pick up". Is that the expectation? I think this will mean that we will have some custom exceptions that providers can throw with an error code.. but we also can handle any sort of exception.

    @Specification(number="2.8", text="In cases of abnormal execution, the provider MUST indicate an " +
            "error using the idioms of the implementation language, with an associated error code having possible " +
            "values PROVIDER_NOT_READY, FLAG_NOT_FOUND, PARSE_ERROR, TYPE_MISMATCH, or GENERAL.")
    @Disabled("I don't think we expect the provider to do all the exception catching.. right?")
    @Test void error_populates_error_code() {
        AlwaysBrokenProvider broken = new AlwaysBrokenProvider();
        ProviderEvaluation<Boolean> result = broken.getBooleanEvaluation("key", false, new EvaluationContext(), FlagEvaluationOptions.builder().build());
        assertEquals(ErrorCode.GENERAL, result.getErrorCode());
    }

[toddbaert]

We might want to update this point not to be prescriptive of the actual error codes, to be consistent with: https://github.com/open-feature/spec/blob/main/specification/flag-evaluation/flag-evaluation.md#requirement-147

It sounds like the thing is saying "If things go bad, you can throw exceptions, but the exceptions must also somehow communicate a string code which the framework will pick up". Is that the expectation?

Yes, that was the idea

I think this will mean that we will have some custom exceptions that providers can throw with an error code.. but we also can handle any sort of exception.

Yep!

I'm up for any proposals to make this point clearer.

On an unrelated note... to reduce thrashing, we might want to break up the provider spec into sub-sections as we have others... that way if we add an intervening point later, it won't cause so many changes.