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

Question

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

tbee opened this issue 7 years ago · comments

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

Ray Tsang · Answer 1 · Thu Jun 08 2017 02:58:05 GMT+0800 (China Standard Time)

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> .

Tom Eugelink · Answer 2 · Thu Jun 08 2017 15:30:42 GMT+0800 (China Standard Time)

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?

Ray Tsang · Answer 3 · Thu Jun 08 2017 16:54:09 GMT+0800 (China Standard Time)

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> .

Tom Eugelink · Answer 4 · Thu Jun 08 2017 17:18:51 GMT+0800 (China Standard Time)

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?

Ray Tsang · Answer 5 · Thu Jun 08 2017 22:44:05 GMT+0800 (China Standard Time)

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.

Tom Eugelink · Answer 6 · Thu Jun 08 2017 23:05:34 GMT+0800 (China Standard Time)

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.

Ray Tsang · Answer 7 · Thu Oct 26 2017 10:19:43 GMT+0800 (China Standard Time)

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