Added throwable logic and convenience methods.

[nwertzberger]

This will make sure that waitSafely throws any unchecked exceptions when it is called. This is super important for using testing libaries with this tool.

---

This change is 

[nwertzberger]

I added in some tests to show when this waitSafely exception handling is so important.

I've also added a Promises convenience class, and a collection convenience method.

[nwertzberger]

This cast was giving me trouble. It wouldn't let me do a FutureTask<?>, saying it gets type erased to Runnable.

[nwertzberger]

Any thoughts?

[saturnism]

quick question - how will this handle multiple failures?

[nwertzberger]

Once an exception has occurred, the code will exit from wherever it is and do what it did before. The only difference is that waitSafely will throw either the first or last exception (your choice).

The key here is that failure behaviors will not change. only the response of waitSafely due to failures.

[nwertzberger]

Is this going to be accepted or not? This change is required to actually use this tool with mockito / most test suites that aren't throwing Error's. Because you eat the exceptions they normally throw.

[saturnism]

hiya - apologies for the slowness on my side. i feel we can merge this in slowly if it was split into 3 PRs:

1. Promises convenience methods - this is pretty useful and independent from many other things in the PR. we can merge this quickly if it was separate.
2. dm.then(Collection<?>...) - would it be useful to strongly type it, then(Collection), and subsequently delegate to then(T ...) ? Having mixed objects in a Collection can be troublesome.
3. finally, error handling - I'm still having a lot of reservations with saving throwables and throwing only in waitSafely. Due to the concurrent nature, errors should be handled in within thread whenever possible. what do you feel about pushing all the errors into a list, and add a way to retrieve it?

[nwertzberger]

I'll have to reflect on that. I can definitely break things up. I really love this library, and, i'm using a fork of it (with this and a few other tweaks - i have quite a few convenience methods at this point) in some pretty rad production code.

I'll try to split up these convenience methods from the other one. Regarding the exception throwing, my thoughts are this:

In my production code, I'm not waiting if i'm using promises, so the waitSafely behavior has little concern from that point of view. It's in my tests where i need the percolation of those runtime exceptions in order to run mockito validate calls / all that. Having additional method calls after waitSafely would make a little bit more verbose, and i really need those exceptions to be thrown in order for my test tooling to catch those as failures.

I don't see any value in getting back more than one exception. If i actually wanted these exceptions, I'd have returned a failed promise.

[saturnism]

Hiya - just got touch base - I'll try to get the Promises util in based on your patch.

In chatting w/ @aalmiray - we may want to explore test utilities that help w/ such cases. In my test cases, I'll catch the exception in the callbacks, and then either re-throw it or check a AtomicBoolean flag.

Finally, based on @aalmiray's suggestion, I'll look into a more generic uncaught error handler so that we can plugin different implementations in case there is an uncaught exception. By default, it'll log it. But when testing, we can potentially fail fast in the handler.

Thanks for your patience on this!

[saturnism]

@nwertzberger quick ping - will it be possible to send in a PR for just the Promises convenience method?

Thanks!