How to perform input validation without exceptions or redundancy

Question

When I'm trying to create an interface for a specific program I'm generally trying to avoid throwing exceptions that depend on non-validated input.

So what often happens is that I've thought of a piece of code like this (this is just an example for the sake of an example, don't mind the function it performs, example in Java):

public static String padToEvenOriginal(int evenSize, String string) {
    if (evenSize % 2 == 1) {
        throw new IllegalArgumentException("evenSize argument is not even");
    }

    if (string.length() >= evenSize) {
        return string;
    }

    StringBuilder sb = new StringBuilder(evenSize);
    sb.append(string);
    for (int i = string.length(); i < evenSize; i++) {
        sb.append(' ');
    }
    return sb.toString();
}

OK, so say that evenSize is actually derived from user input. So I'm not sure that it is even. But I don't want to call this method with the possibility that an exception is thrown. So I make the following function:

public static boolean isEven(int evenSize) {
    return evenSize % 2 == 0;
}

but now I've got two checks that perform the same input validation: the expression in the if statement and the explicit check in isEven. Duplicate code, not nice, so let's refactor:

public static String padToEvenWithIsEven(int evenSize, String string) {
    if (!isEven(evenSize)) { // to avoid duplicate code
        throw new IllegalArgumentException("evenSize argument is not even");
    }

    if (string.length() >= evenSize) {
        return string;
    }

    StringBuilder sb = new StringBuilder(evenSize);
    sb.append(string);
    for (int i = string.length(); i < evenSize; i++) {
        sb.append(' ');
    }
    return sb.toString();
}

OK, that solved it, but now we get into the following situation:

String test = "123";
int size;
do {
    size = getSizeFromInput();
} while (!isEven(size)); // checks if it is even
String evenTest = padToEvenWithIsEven(size, test);
System.out.println(evenTest); // checks if it is even (redundant)

now we've got a redundant check: we already know that the value is even, but padToEvenWithIsEven still performs the parameter check, which will always return true, as we already called this function.

Now for isEven of course doesn't pose a problem, but if the parameter check is more cumbersome then this may incur too much cost. Besides that, performing a redundant call simply doesn't feel right.

Sometimes we can work around this by introducing a "validated type" or by creating a function where this issue cannot occur:

public static String padToEvenSmarter(int numberOfBigrams, String string) {
    int size = numberOfBigrams * 2;
    if (string.length() >= size) {
        return string;
    }

    StringBuilder sb = new StringBuilder(size);
    sb.append(string);
    for (int i = string.length(); i < size; i++) {
        sb.append('x');
    }
    return sb.toString();
}

but this requires some smart thinking and quite a large refactor.

Is there a (more) generic way in which we can avoid the redundant calls to isEven and performing double parameter checking? I'd like the solution not to actually call padToEven with an invalid parameter, triggering the exception.

---

With no exceptions I do not mean exception-free programming, I mean that user input doesn't trigger an exception by design, while the generic function itself still contains the parameter check (if just to protect against programming errors).

Answer 1

In the case of your example, the best solution is to use a more general padding function; if the caller wants to pad to an even size then they can check that themselves.

public static String padString(int size, String string) {
    if (string.length() >= size) {
        return string;
    }

    StringBuilder sb = new StringBuilder(size);
    sb.append(string);
    for (int i = string.length(); i < size; i++) {
        sb.append(' ');
    }
    return sb.toString();
}

If you repeatedly perform the same validation on a value, or want to only allow a subset of values of a type, then microtypes / tiny types can be helpful. For general purpose utilities like padding this is not a good idea, but if your value plays some particular role in your domain model, using a dedicated type instead of primitive values can be a great step forward. Here, you might define:

final class EvenInteger {
  public final int value;

  public EvenInteger(int value) {
    if (!(value % 2 == 0))
      throw new IllegalArgumentException("EvenInteger(" + value + ") is not even");
    this.value = value;
  }
}

Now you can declare

public static String padStringToEven(EvenInteger evenSize, String string)
    ...

and don't have to do any inside validation. For such a simple test wrapping an int inside an object will likely be more expensive in terms of run time performance, but using the type system to your advantage can reduce bugs and clarify your design.

Using such tiny types can even be useful even when they perform no validation, e.g. to disambiguate a string representing a FirstName from a LastName. I frequently use this pattern in statically typed languages.

Answer 2

As an extension to @amon's answer, we can combine his EvenInteger with what the functional programming community might call a "Smart Constructor" -- a function that wraps the dumb constructor and makes sure that the object is in a valid state (we make the dumb constructor class or in non-class based languages module/package private to make sure only the smart constructors are used). The trick is to return an Optional (or equivalent) to make the function more composable.

public final class EvenInteger {
    private final int value;

    private EvenInteger(value) {
        this.value = value;
    }

    public static Optional<EvenInteger> of(final int value) {
        if (value % 2 == 0) {
            return Optional.of(new EvenInteger(value));
        }
        return Optional.empty();
    }

    public int getValue() {
        return this.value;
    }
}

We can then easily use standard Optional methods to write the input logic:

class GetEvenInput {
    public Optional<EvenInteger> askOnce() {
        int size = getSizeFromInput();
        return EvenInteger.of(size);
    }

    public EvenInteger keepAsking() {
        return askOnce().orElseGet(() -> keepAsking());
    }
}

You could also write keepAsking() in a more idiomatic Java style with a do-while loop.

Optional<EvenInteger> result;
do {
    result = askOnce();
} while (!result.isPresent());

return result.get();

Then in the rest of your code you can depend on EvenInteger with certitude that it really will be even and our even check was only ever written once, in EvenInteger::of.

Answer 3

Doing validation twice is a problem if the result of the validation is the same AND the validation is being done in the same class. That is not your example. In your refactored code, the first isEven check that is done is an input validation, failure results in a new input being requested. The second check is completely independent of the first, as it is on a public method padToEvenWithEven which can be called from outside of the class and has a different result (the exception).

Your problem is similar to the problem of accidentally identical code being confused for non-dry. You are confusing the implementation, with the design. They aren't the same, and just because you have one or a dozen lines that are the same, doesn't mean that they are serving the same purpose and can forever be consided interchangeable. Also, probably having your class do too much, but skip that as this is probably just a toy example...

If this is a performance issue, you can solve the problem by creating a private method, that doesn't do any validation, which your public padToEvenWithEven called after doing it's validation and which your other method would call instead. If it's not a performance issue, then let your different methods do the checks that they require to do their assigned tasks.