Hacker News new | comments | show | ask | jobs | submit login

Personally, any solution to callback hell will also need to be a language that supports returning multiple values. The following convention is simply too useful to me:

  foo.doSomethingAsync(function(err, result) {
    if (err) {
      ...
    }
    ...
  });
You can obviously accomplish this with exceptions, but then you have a million try/catch blocks floating around all over the place and the code becomes even harder to read (and more verbose to boot).



There's a way without exceptions. Use an ErrorT[Promise[A]] monad. I've done this in Scala before and it is so much simpler than the JavaScript convention you pointed out.

It allows you to write code like this:

    val query = "Brian"
    val result = for {
      db <- connectToDatabase
      user <- userFromDatabase(db, query)
      friends <- friendsFromDatabase(db, user.friends)
    } yield friends
Whenever one of the functions above returns an error, the whole expression is that error. The outcome is either an error (if there was any) or the end value of Set[User]. No need to manually handle an error until you get to the end result.


Similar to this is the Scala fold convention.

An example from the Play! Framework for form submissions:

    def submit = Action { implicit request =>
      contactForm.bindFromRequest.fold(
        errors => BadRequest(html.contact.form(errors)),
        contact => Ok(html.contact.summary(contact))
      )
    }


That's basically what the promises spec for Javascript gives you.


Exactly. The promises spec defines the Promise monad. The problem is that JavaScript doesn't have monadic syntax, which would make the code a lot more readable.


I've always seen this as an odd convention. Why not

if (typeof result === Error) {


There's a very good reason for returning a result as (error_code, resulting_data) instead of just returning a single value of resulting_data and then having the caller check to see if resulting_data is an error.

The problem is that if you count on the caller to check on the error value for the data, he might forget to do that. And the code works just fine in testing, and it seems like it works. But in the error case, we merrily continue on and try to pass the error around as if it were data.

When we return two values, error and data, then the developer is forced to think about the fact that the result could be an error, and think right then about what should happen. THis is a good place to be thinking about it.

Also, the developer may not even know at-a-glance that the function could sometimes return an error, unless consulting the documentation.

Or more succinctly: it's not about making the code easier to write (which the version you mentioned does); it's instead about making it easier to do the right thing.


  foo.doSomethingAsync(function(result) {
    ...
  }, function(err) {
    ...
  });


Yeah, but try to chain three async functions in that style and it becomes evident what pufuwozu meant when they said monads made the code simpler.


Deferreds in Twisted make it easy to chain asynchronous code with error handling together:

    def parseData(data):
        return doManyFancyThingsWith(data)
    
    def parsedAsyncResult():
        return asyncResult().addCallback(parseData)

    def callback(data):
        print 'Parsed data:', data
    def errback(err):
        print 'Oh no, something went wrong!'
    parsedAsyncResult().addCallbacks(callback, errback)
If an error is raised by either asyncResult() or parseData(), it will be caught by the errback function, even though parsedAsyncResult() didn't explicitly do anything to pass errors along.


That looks like an unnecessarily confusing way of writing this code:

    try:
        data = doManyFancyThingsWith(asyncResult())
        print 'Parsed data:', data
    except:
        print 'Oh no, something went wrong!'
That's the code I would write if I were using Eventlet or Gevent, and it would work just fine. Why settle for less? It's 2012, damn it; we shouldn't have to dick around with deferreds except under exotic circumstances.


This is possible in Twisted, using inline callbacks:

  try:
      data = doManyFancyThingsWith(yield asyncResult())
      print 'Parsed data:', data
  except:
      print 'Oh no, something went wrong!'
I find that I use inline callbacks for the common case and work with deferreds directly only when it makes more sense to handle callbacks explicitly.


I don't know, I find this quite readable:

  foo.doSomethingAsync(function(result) {
    ...
  }, {
  error: function(err) {
    ...
  },
  afterward: function(then) {
    ...
  },
  evenLater: function(wat) {
    ...
  }});
Which is not meant in any way to imply that there's nothing better :) Just that I see no reason to make the comparison to an abnormally-bad version.


When would the "evenLater" callback be called?

Besides, that's still only one function call. When you need to call many async things one after the other (that's what i meant by "chaining"), that nested callback-based code becomes much much convoluted than the analogous "normal" return-based code.

With promise monads [1] or some sort of language transformation that lets you write code that looks sequential but then is transformed into chained callbacks, you can basically get rid of all those extra callback functions and their associated complexity (i.e. all the mangled "success" and "error" callbacks from chained async functions) and have code that looks normal function calls one after the other. Notice that pufuwozu's example had three consecutive async calls, but it didn't need to create all the callback functions to pass between the calls.

[1]: This is a nice little spec for chainable promises: http://wiki.commonjs.org/wiki/Promises/A. And here's a post that explains how they are used: https://gist.github.com/3889970




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: