Question: I have javascript array with a teaching hour of a teacher in a day

```
{
"time": [
  { "start":"10:00","end":"11:00" },
  { "start":"12:00","end":"01:00" },
  { "start":"04:00","end":"06:00" }
]
}

```

I want to find out free hour of from above array between **10 AM to 6PM**

Output array will like this :

```
{
"time": [
  { "start":"09:00","end":"10:00" },
  { "start":"11:00","end":"12:30" },
  { "start":"01:00","end":"04:00" }
]
}

```

please help me out to solve this

Answer: 
Chaining like you are currently doing is generally the best solution. It is easy to understand, efficient and (relatively) concise.

A couple of other ideas would be:

* build an array of predicates and then iterate and call them, or
* use exceptions and exception handling

but both of these have performance implications, and they will only give "cleaner" code if you have a vast number of predicates to evaluate.

Sometimes an inelegant solution is more elegant than looking for a clever solution.

---

Consider this: if I use exceptions, I can rewrite the `validate()` method

```
private boolean validate(){
    return checkOne() && checkTow() && checkThree() && checkFour();
}

```

as 

```
private void validate() throws ValidationException {
    checkOne(); checkTow(); checkThree(); checkFour();
}

```

But how much have I actually gained here? It is still two lines of code. And if I were to follow Java's style rules it would be:

```
private void validate() throws ValidationException {
    checkOne(); 
    checkTow(); 
    checkThree(); 
    checkFour();
}

```

which is *more* lines than we started with. And we haven't considered the predicates themselves or the code that handles the validation exception.
Convenionally you would use exceptions:

```
void check1(Foo value) {
    if(some test on value) {
        throw new ValidationException(...);
    }
}

try {
    check1(value);
    check2(value);
} catch (ValidationException e) {
    // deal with validation failure
}

```

A bonus here is that the exception can carry information about the failure. Your boolean `false` just says "it failed", with no explanation.

Another bonus, of course, is that you're free to pass the exception higher up the call stack, where some other code can deal with it.

Some people worry about the cost of building exceptions (or more accurately, collecting that stack trace contained within). I'd advise not worrying about it unless you get performance problems and profiling points the finger at exceptions.

---

There are alternatives though. For example your validation could return `Optional<ValidationError>`:

```
Optional<ValidationError> check1(Foo value) {
   if(some test on value) {
       return Optional.of(new ValidationError(...));
   } else {
       return Optional.empty();
   }
}

```

Then...

```
Optional<ValidationError> validationResult = 
     check1(value)
     .orElseGet( () -> check2(value))
     .orElseGet( () -> check3(value));

```

You could, of course, loop through a list of validators, rather than hard-code like this.

Some of the functional programming libraries (e.g. vavr) include an `Either` class, which can be used in a similar way, where instead of being either an error or `empty()`, it's an error or a success value.

---

Or you could stick with methods returning boolean, but use them as `Predicate`s:

```
 List<Predicate<Foo>> checks = Arrays.asList(
      f -> check1(f),
      f -> check2(f),
      f -> check3(f)
 );

```

(Or the equivalent with method references e.g. `this::check1`)

```
checks.stream().allMatch(check -> check.test(value));

```

---

As you can see, there are tons of possibilities. But think about whether you're over-complicating. There's mostly nothing inherently wrong with the simple approach you already have -- although it *is* better, and more testable, to return a failure reason, rather than print it as a side-effect.