From af49a7dcb46ec785c7d29829843934c5292c1339 Mon Sep 17 00:00:00 2001 From: Barney Carroll Date: Tue, 21 Jun 2016 10:09:59 +0100 Subject: [PATCH] Long-term Node fans might take exception (lol)... ...to saying there aren't *any* mechanisms for error-handling in callback-centric async APIs --- docs/request.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/request.md b/docs/request.md index ed04b42b..761c8c76 100644 --- a/docs/request.md +++ b/docs/request.md @@ -122,7 +122,7 @@ Normally, XMLHttpRequest makes HTTP requests to a server *asynchronously*. This Some older libraries do so via callback functions, and newer ones (including the `fetch` API) return [promises](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise). `m.request` returns *reactive streams*. -Callback functions are the most basic mechanism for asynchronous flow control. They are not *composable* because they require the callback function to be passed at call time, and they don't provide any mechanism for handling errors. +Callback functions are the most basic mechanism for asynchronous flow control. They are not *composable* because they require the callback function to be passed at call time, and error handling mechanisms must similarly be declared upfront. However, it's desirable to allow the callback function to be defined (and broken into subroutines) in different places than the call site, in order to achieve better separation of concerns. In addition, it's also desirable to wrap an abstraction around errors so that they can be thrown freely and handled safely from a single place, rather than requiring `try/catch` blocks in every callback function, or duplicating error handling code. The problems that arise from callbacks' lack of composability are [infamous enough](http://callbackhell.com/) to earn nicknames such as "callback hell" and "pyramids of doom". @@ -248,4 +248,4 @@ findProject(123).map(project) Doing so updates all the streams, and therefore there's no need to place the filtering code in the view, where the filtering code would recompute the same thing on every render. -Returning streams from `m.request` streamlines use cases where efficient reactivity is desired, without losing the composable semantics of promises. \ No newline at end of file +Returning streams from `m.request` streamlines use cases where efficient reactivity is desired, without losing the composable semantics of promises.