handle: A Range that handles an Exception

When a Exception occurs inside a range chaining the whole chain dies usually. The Handle range fixes that, as it catches a defined exception and calls an user defined handler on it.
It's not uncommon for ranges to do prep work in their constructor which could iterate over the range that they're wrapping. `filter` does exactly that. It will iterate until it finds an element which matches the predicate, which means that it could (if no element matches the predicate) iterate over the entire range before `filter` even returns. For `handle` to not do the same poses two problems:

1. It essentially violates how ranges work. `empty` needs to return whether the range is empty, whereas with your current implementation, it can't. It just returns `true` if it _knows_ that it's empty, but it doesn't always know. `false` means nothing, because `front` could be forced to iterate through the rest of the elements and then throw because there are no more elements to return - i.e. the range is empty. `front` should never throw because there is no element. `empty` needs to be `true` if there are no elements left.

2. The primary use case for `handle` is `foreach`. And not only would that iterate over all of the elements normally anyway (making your concern about iterating through the whole range in the constructor irrelevant to the primary use case), but it means that the caller needs to worry about `front` throwing, forcing them to wrap `foreach` in  try-catch block instead of being able to just iterate over the range and let the handler deal with all of the exceptions which get thrown.

I would argue that anyone who really doesn't want `handle` to iterate over anything in its constructor should just iterate over the range manually, in which case they can use something like `ifThrown` to deal with any exceptions that get thrown while iterating. Having `front` throw does not fit in with how ranges work and does not fit in with `handle`'s primary use case - `foreach`. And having `ExceptionHandler`'s constructor iterate until it finds a valid `front` or empties the range is exactly in line with existing functions such as `filter`.

While I can appreciate not wanting the underlying range to be emptied before `handle` even returns if every element throws, I don't think that it's really going to be a problem, and I don't think that it really makes sense to do it any other way given how ranges work and how `handle` is likely to be used.