Revise nullability of `getMessage()` in `ParameterResolutionException`

[wimdeblauwe]

The ParameterResolutionException class is part of a @NullMarked package. The constructors currently look like this:

	public ParameterResolutionException(String message) {
		super(message);
	}

	public ParameterResolutionException(String message, Throwable cause) {
		super(message, cause);
	}

To align with the JUnitException it extends from, this should be changed to:

	public ParameterResolutionException(@Nullable String message) {
		super(message);
	}

	public ParameterResolutionException(@Nullable String message, @Nullable Throwable cause) {
		super(message, cause);
	}

In my project NullAway gives an error for this construct:

    } catch (Exception e) {
      throw new ParameterResolutionException(e.getMessage(), e);
    }

Because e.getMessage() can return null, but ParameterResolutionException now claims it does not accept null.

[sbrannen]

IIRC, it's by design that the message cannot be null.

We don't ever want a ParameterResolutionException to be thrown without a message.

Thus, I think we should rather override getMessage() to be non-nullable and reject any null message supplied to a ParameterResolutionException constructor -- for example, like super(Objects.requireNonNull(message, "message must not be null"));

[sbrannen]

In my project NullAway gives an error for this construct:

} catch (Exception e) {
  throw new ParameterResolutionException(e.getMessage(), e);
}

FWIW, I would not recommend the use of e.getMessage() for the message: the message should be specific to the current use case and not simply repeat the message that's already available in the supplied e.

[wimdeblauwe]

I agree with your remark on the use of e.getMessage(), will change that on my side.

[sbrannen]

Thus, I think we should rather override getMessage() to be non-nullable and reject any null message supplied to a ParameterResolutionException constructor -- for example, like super(Objects.requireNonNull(message, "message must not be null"));

Based on feedback within the team, let's go that route but use Preconditions instead of Objects in the super(...) invocations.