With multiple results it is hard to access the cause of the failure

[tbee]

On normal calls, the fail method has the exception as the parameter. When syncing multiple calls, the fail method returns a OneReject instance. But it is not easy (if even possible) to access the exception causing the failure through that instance.
https://github.com/jdeferred/jdeferred/blob/master/subprojects/jdeferred-core/src/main/java/org/jdeferred/multiple/OneReject.java

[saturnism]

Ah, it feels like OneReject should have the rejection type as a generic. Would that help w better type safety?

…

On Wed, Jun 7, 2017 at 12:46 PM Tom Eugelink ***@***.***> wrote: On normal calls, the fail method has the exception as the parameter. When syncing multiple calls, the fail method returns a OneReject instance. But it is not easy (if even possible) to access the exception causing the failure through that instance. https://github.com/jdeferred/jdeferred/blob/master/subprojects/jdeferred-core/src/main/java/org/jdeferred/multiple/OneReject.java — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB6AI65JQKXTKfy7bMw5J4luUHThkOiFks5sBnFvgaJpZM4Nyddz> .

[tbee]

This is not about type safety; I just want to know what caused the fail to be called. The 'normal' fail gets the causing exception as a parameter, where is it hidden here? ... Hmm, is it maybe the reject value in OneReject?

[saturnism]

Iirc, It should be in the OneReject.getReject() But you do need to an instanceof and then casting it

…

On Thu, Jun 8, 2017 at 10:30 AM Tom Eugelink ***@***.***> wrote: This is not about type safety; I just want to know what caused the fail to be called. The 'normal' fail gets the causing exception as a parameter, where is it hidden here? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB6AIwWGeQ_REl1ZSPlfcq6uB4OJ87g5ks5sB6MjgaJpZM4Nyddz> .

[tbee]

Ok. I see. And I see that the other fail method also has a parameter of type Object. Isn't that always a Throwable or Exception?

[saturnism]

not quite, you can reject with a non-Exception. E.g., deferred.reject("failed")

However, if you let DeferredManager to create a promise from a Callable, then the rejection is always an Exception.

[tbee]

Ok! With the javascript roots I get that. I would have wrapped that reject in an exception so the API would be identical. Butthat explains it. Thanks.

[saturnism]

Sounds like we were good. Closing for now :) Thanks!