Error-hook and the downsides of exceptions in java

Currently our error hook specification reads as follow:

The `error` hook **MUST** run when errors are encountered in the `before` stage, the `after` stage or during flag resolution. It accepts `hook context` (required), `exception` representing what went wrong (required), and `hook hints` (optional). It has no return value.

which translates in Java to:

void error(HookContext<T> ctx, Exception error, Map<String, Object> hints)

This is great, and an easy way to simple handle exceptions., but it comes with a downside. We are using exception especially for the case where flags not found, or disabled for flow control.

This adds unnecessary overhead, and might not be the best approach as Java exception add overhead, and in this case those are not exceptions per se. Eg. in flagd we already implemented an approach, where we are not throwing those exception but use them as POJO.
Still it is not a good coding practice to instantiate a class dedicated for throwing without throwing it.

So I am not sure, if we need to adapt the spec here, or if we only need to adapt the java interface.

Java proposal

We could instead of using the exception, create an own ErrorDetails.

public class ErrorDetails  {
    OpenFeatureError error;
    FlagEvaluationDetails evaluationDetails
}

and changing the interface to:

void error(HookContext<T> ctx, ErrorDetails error, Map<String, Object> hints)

Proposal to change description of hooks

The `error` hook **MUST** run when errors are encountered in the `before` stage, the `after` stage or during flag resolution. It accepts `hook context` (required), `errorDetails` representing what went wrong (required, **MUST** contain an exception or an errorneous FlagEvaluationDetails ), and `hook hints` (optional). It has no return value.

Question

should we only do this for the java world, or does an overall improvement for the error hook in general might be a good idea. Eg. having an own object would allow us to be more flexible in the future anyways.

WDYT?

Start by reviewing the current error-hook specification and the Java proposal in this issue, then compare them with the flagd approach mentioned in the discussion. Determine whether the change belongs only in the Java interface or requires a general hook-spec update. Done means reaching and documenting a decision on the error representation and its required contents.