mplatvoet
commented
9 years ago Yes there is. When we change the interface to Throwable we would also implicitly state that we handle any subclass of Error. Besides catching Errors is being considered an unrecommended practice it also doesn't make much sense in most cases. E.g. we can't really recover from an OutOfMemoryError or other virtual machine Errors. There is only one exception, as far as I know, and that is StackOverflowError which we actually can recover from.
But to me it makes much more sense to actually let those Errors crash the program as there needs to be something fixed in the user code (e.g. no unbounded recursion) or altered on the platform it's running on (e.g. more memory).
That being said, I purposely let the interface Promise<V, E> and Deferred<V, E> open for any use case you might have. So whether you want it to be Throwable or something like String that's possible. As an alternative to wrapping Throwables in Exceptions you could also write your own support methods like then and async. Wouldn't be much effort to create you own flavour as you can see by the current implementation
apatrida
Is there a reason we can't have one for Throwable instead of just Exception? For example, Vert.x always types their exceptions callback handlers with Throwable, so would have to wrap every exception otherwise.