Guest User

Untitled

a guest
Jun 17th, 2018
76
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.37 KB | None | 0 0
  1. (10/11/2010 10:49:36 AM) Vladimir1: Hi! Saw you posted about you don;t like how exception handling is done currently in promised-io/promise. What were those helpers you mentioned you developed?
  2. (11:16:23 AM) deanlandolt: i didn't develop helpers for that...i thought kris mentioned something to you about developing something...something like a different style of when...i was saying i'm working on some helpers for framing streams
  3. (11:26:08 AM) Vladimir1: ah, i see. what he proposed was whenCall() which is fed with not direct promise, but a function returning that promise. I found that is not so useful since another indirection level ugly-fies the code...
  4. (11:26:49 AM) deanlandolt: it's fed with a function that MAY return a promise, but may also return immediately...or *throw*
  5. (11:27:48 AM) deanlandolt: that's the key...we have to trap that through...the only way to do that is to trap is with a new lexical scope (the function passed to whenCall)...the only /other/ way is to actual try/catch IN your code, and share the handler...having written a bunch of code like that i'd say that's uglier
  6. (11:28:22 AM) Vladimir1: the whole purpose of the function is to delay obtaining the "meta-promise" (true promise or immediate value) thus making able to try/catch within whenCall() and reuse the handlers. Right?
  7. (11:28:41 AM) deanlandolt: no, that's not it at all
  8. (11:28:58 AM) Vladimir1: please, clarify
  9. (11:29:07 AM) deanlandolt: if the function returns a promise you don't have to worry about that...you can catch any errors (rejections, technically) in the third argument passed to when
  10. (11:29:25 AM) deanlandolt: it's if it DOESN'T reject, but instead throws (e.g. it's not a promised value but an actual type)
  11. (11:29:43 AM) deanlandolt: so say you have fn1 that throws when called...
  12. (11:29:59 AM) Vladimir1: yes
  13. (11:30:00 AM) deanlandolt: when(fn1(), function() {}, function(e) { /* i don't get called */ })
  14. (11:30:08 AM) Vladimir1: true
  15. (11:30:08 AM) deanlandolt: so you'd ahve to do this instead:
  16. (11:30:21 AM) deanlandolt: var fn1MayBePromise;
  17. (11:30:42 AM) deanlandolt: try { fn1MayBePromise = fn1();
  18. (11:30:56 AM) deanlandolt: } catch(e) { handleError(e) }
  19. (11:31:22 AM) deanlandolt: when(fn1MayBePromise, function(value) { /* success handler */ }, function(e) { handleError(e) });
  20. (11:31:27 AM) deanlandolt: function handleError(e) { /* one fn to handle both types of errors */ }
  21. (11:32:02 AM) deanlandolt: see where i'm going w/ that? that's what whenCall fixes...
  22. (11:32:41 AM) deanlandolt: whenCall(function() { return fn1(); }, function(value) { /* success, no matter if i'm a promise or not */ }, function(e) { /* error, whether i'm a promise or not */})
  23. (11:34:42 AM) Vladimir1: so fn1() return a value on success and throw on error
  24. (11:34:52 AM) deanlandolt: fn1 may return a promise for all you know
  25. (11:35:13 AM) Vladimir1: how in fn1() i indicate the error state?
  26. (11:35:16 AM) deanlandolt: but it's POSSIBLE that it throws on error (even if it usually returns a promise...say you screwed up w/ the arguments you passed in)
  27. (11:35:42 AM) deanlandolt: the simple fact that it throws is enough...since we're trapping it in a function that whenCall calls, whenCall can do the try/catch wrapping for you
  28. (11:36:34 AM) deanlandolt: it's just a convenience to keep you from having to do the thing i showed you first (getting the promise value in a try/catch and sharing an errorHandler with the promise rejection and catch clauses)
Add Comment
Please, Sign In to add comment