mikeash.com pyblog/friday-qa-2010-02-05-error-returns-with-continuation-passing-style.html comments

mikeash - 2017-07-14 17:08:26

Fri, 14 Jul 2017 17:08:26 GMT

I think you can do it even better with Swift errors, since you can write a single generic adapter function instead of writing a bunch of adapter methods. For example:

func handle<T>(_ call: @autoclosure () throws -> T, errorHandler: (Error) -> Void, continuation: (T) -> Void) {

    do {

        let value = try call()

        continuation(value)

    } catch {

        errorHandler(error)

    }

}



enum E: Error {

    case e

}



func f() throws -> String {

    return "Hello, world"

}



func g() throws -> String {

    throw E.e

}



handle(try f(), errorHandler: {

    print("error: \($0)")

}, continuation: {

    print("success: \($0)")

})

handle(try g(), errorHandler: {

    print("error: \($0)")

}, continuation: {

    print("success: \($0)")

})

However, I think Swift's error handling system is good enough to obsolete this whole idea.

Doug - 2017-07-13 21:39:59

Thu, 13 Jul 2017 21:39:59 GMT

I like this a lot but now that Swift converts NSErrors to throws it's hard to adopt :(

https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/AdoptingCocoaDesignPatterns.html

If the last non-block parameter of an Objective-C method is of type NSError **, Swift replaces it with the throws keyword, to indicate that the method can throw an error. If the Objective-C method’s error parameter is also its first parameter, Swift attempts to simplify the method name further, by removing the “WithError” or “AndReturnError” suffix, if present, from the first part of the selector. If another method is declared with the resulting selector, the method name is not changed.

If an error producing Objective-C method returns a BOOL value to indicate the success or failure of a method call, Swift changes the return type of the function to Void. Similarly, if an error producing Objective-C method returns a nil value to indicate the failure of a method call, Swift changes the return type of the function to a nonoptional type.

Steve - 2012-01-25 06:01:16

Wed, 25 Jan 2012 06:01:16 GMT

Interesting ideas... One of the downsides of CPS in Haskell and other FP languages is the nesting that inevitably occurs, as displayed by your example in the contents. Monadic notation does a lot to fix this (do ...) - wonder if the same pattern can be applied here in order to come up with an even cleaner notation? Need to define >>, >>= equivalents, and maybe a #define for the do notation...

mikeash - 2010-05-19 19:46:55

Wed, 19 May 2010 19:46:55 GMT

That is neat! I didn't know JQuery had that. Would translate almost perfectly into ObjC with blocks.

slf - 2010-05-19 14:07:00

Wed, 19 May 2010 14:07:00 GMT

Using blocks in this way could make some kind of interesting Obj-C flavor of javascript. jQuery aggressively uses this technique:



$.ajax({

   type: "POST",

   url: "some.php",

   data: "name=John&location=Boston",

   success: function(msg){

     alert( "yay!" );

   },

   error: function(xr, s, e) {

     alert( "aww :(" );

   }

 });

http://api.jquery.com/jQuery.ajax/

mikeash - 2010-05-18 15:47:58

Tue, 18 May 2010 15:47:58 GMT

Python can't return multiple values in the same way that C can't pass function parameters by reference. It's true, but existing language features combine to give you functionality that's indistinguishable. Python effectively has multiple value return, even if it's actually just tuple packing and unpacking, the same way that C effectively has pass-by-reference, even though it's actually just passing a pointer by value.

Filip van der Meeren - 2010-05-18 15:35:19

Tue, 18 May 2010 15:35:19 GMT

I disagree about your statement that Python has the ability to return multiple values.

Python is able to return a list or tuple. Automatic unpacking allows you to unpack the array in multiple values:

aTuple = ("value1", "value2", "value3", "value4")
value1, *value2and3, value4 = aTuple

# Is the same as
aTuple = "value1", "value2", "value3", "value4"
value1, *value2and3, value4 = aTuple

# Is the same as
def aFunction():
return "value1", "value2", "value3", "value4"

value1, *value2and3, value4 = aFunction()

Kevin Ballard - 2010-03-27 23:55:39

Sat, 27 Mar 2010 23:55:39 GMT

One potential pitfall I can see with doing heavy CPS style is that, IIRC, GCC does not do tail-call optimization, which means that each new continuation introduces a new stack frame. Stacks are pretty large these days so you're not likely to run into a problem, but the possibility is still there. Of course, if you're using LLVM I believe that does tail-call optimization now.

Remy Demarest (Psy|) - 2010-02-10 17:08:21

Wed, 10 Feb 2010 17:08:21 GMT

I've written this little code to add SmallTalkish methods to ObjC using blocks. The last part of the example shows a way to use continuations:

http://gist.github.com/239363

mikeash - 2010-02-08 17:10:41

Mon, 08 Feb 2010 17:10:41 GMT

Raising an error makes sense. Thanks for the explanation.

Objective-C blocks are already doing return type inference. Declaring the return type of a block is possible but not mandatory. This inference could be used for implicit returns as well. Really, implicit return is just a bit of syntactic sugar in this case. It's just like putting the return keyword right before the last statement in the block.

Karsten - 2010-02-08 08:56:01

Mon, 08 Feb 2010 08:56:01 GMT

in your example, if you evaluate the block later, this will raise an error that the context cannot return.

As for the implicit return of blocks. That would be great, but that just doesn't work in the c-based Objective-C, where you explicitly need to declare the return type.

mikeash - 2010-02-08 03:41:59

Mon, 08 Feb 2010 03:41:59 GMT

An interesting question. The best I can come up with is that returning the string directly forces you to have an if statement, which is avoided with the pure CPS approach. E.g.:

NSString *myString = [obj ...message];
if(myString)
{
// it's good
}

Versus:

[obj ...message: ^(NSString *myString) {
// it's good
}];

The rest is basically the same amount of code, so you save the if statement. You also lose the convenience of having code flow return directly to your method body....

Scott Little - 2010-02-08 00:08:42

Mon, 08 Feb 2010 00:08:42 GMT

I really like this idea a lot, but there is one thing I don't really see.... The need for the second part, i.e. the continuation block. If you have this signature:

stringWithContentsOfFile:encoding:errorHandler:continuation:

I don't really see the advantage to having the continuation block at all! If I don't error give me back the string and let my program continue its normal flow, but let the block handle any errors.

How does that second block help me out?

Thanks for the great posts.

mikeash - 2010-02-06 17:59:31

Sat, 06 Feb 2010 17:59:31 GMT

My question about the return operator was more like this (forgive my presumably-poor syntax, since I've never really written Smalltalk):

Person>>something

    ^[^nil]

In other words, you return the block from the enclosing method, then call it somewhere later, but it still contains a ^ statement. I know this probably makes no sense to do intentionally, but I'm wondering what happens if you try it anyway.

Given the discussion about Smalltalk, I'm finding myself wishing that Objective-C blocks had the same semantic where the block's value is simply the value of its last expression. Having to write return everywhere is annoying and sometimes confusing.

Karsten - 2010-02-06 17:10:13

Sat, 06 Feb 2010 17:10:13 GMT

Coming from Smalltalk, i've also enjoyed using error-blocks as arguments a lot. In Smalltalk querying a dictionary for a key that's not in the dictionary raises an error. So the common way of getting values out of a dictionary is not #objectForKey: but more along the lines of #objectForKey:ifAbsent:. The second parameter is a block that is evaluated when the key is absent.

I'm not sure if that already addresses your question about the return operator before, but you can write a method #street like this in a class Person:



Person>>street

   | address |

    address := addresses at: self ifAbsent:[^nil].

    ^address street

If there is no address for the given person, it'll execute the error-block. In that block is a return, so the #street method returns nil. If an address was found, the #at:ifAbsent: would return this address and would not evaluate its error-block.
Thus the method does only return after "address street" is evaluated.

Nikita Zhuk - 2010-02-06 12:04:32

Sat, 06 Feb 2010 12:04:32 GMT

Your last example looks like the most readable, but you're correct that it probably isn't the most realistic example.

I really like the idea of CPS, but I think (at least with current syntax) it decreases the readability of the code. In first example, the indentation level (which is actually conditional nesting level in this case) grows from 1 to 4, in second example from 1 to 2 and requires the developer to break the method into smaller ones, which may or may not be desirable (if the original method is already performing a single semantic thing and all method calls are on the same abstraction level, it may not make sense to break it down).

mikeash - 2010-02-06 07:36:58

Sat, 06 Feb 2010 07:36:58 GMT

An interesting question. This is a basic translation:

- (BOOL)doSomething 

{

    __block BOOL returnValue = NO;

    

    [obj objectWhateverWithErrorHandler: ^(NSError *) {

            [self _handleError: error];

        }

        continuation: ^(id obj1) {

            [obj1 objectWhateverWithErrorHandler: ^(NSError *) {

                [self _handleError: error];

            }

            continuation: ^(id obj2) {

            [obj2 objectWhateverWithErrorHandler: ^(NSError *) {

                    [self _handleError: error];

                }

                continuation: ^(id obj3) {

                    returnValue = YES;

                }];

            }];

        }];

    return returnValue;

}

The nesting does get a bit ugly, but I don't find it to be too horrible. In reality, I would probably rewrite it as a series of smaller methods:

- (BOOL)doSomething

{

    __block BOOL returnValue = NO;

    [obj objectWhateverWithErrorHandler: ^(NSError *) {

            [self _handleError: error];

        }

        continuation: ^(id obj1) {

            returnValue = [self doSomethingWithObj1: obj1];

        }];

    return returnValue;

}

If you want to get fancy, take advantage of the fact that your three error handlers are all identical, and define that handler up front so you just pass a variable in to each one:

- (BOOL)doSomething

{

    __block BOOL returnValue = NO;

    

    void (^errorHandler)(NSError *) = ^(NSError *) { [self _handleError: error]; };

    

    [obj objectWhateverWithErrorHandler: errorHandler continuation: ^(id obj1) {

        [obj1 objectWhateverWithErrorHandler: errorHandler continuation: ^(id obj2) {

            [obj2 objectWhateverWithErrorHandler: errorHandler continuation: ^(id obj3) {

                returnValue = YES;

            }];

        }];

    }];

    return returnValue;

}

I find this to look really nice, but I don't know how likely it would be to find a situation where you could use it in real code.

Nikita Zhuk - 2010-02-06 07:07:19

Sat, 06 Feb 2010 07:07:19 GMT

How the CPS style affects readability of a method which has several method calls which may return NSError values and which are handled within the method, i.e. the method doesn't pass NSError up to the caller? Imagine the following method written with standard error conventions:



- (BOOL)doSomething

{

    NSError *error = nil;

    id obj1 = [obj objectWhateverWithError:&error];

    if(obj1 == nil)

    {

        [self _handleError:error]

        return NO;

    }

    

    id obj2 = [obj1 objectWhateverWithError:&error];

    if(obj2 == nil)

    {

        [self _handleError:error]

        return NO;

    }

    

    id obj3 = [obj2 objectWhateverWithError:&error];

    if(obj3 == nil)

    {

        [self _handleError:error]

        return NO;

    }

    return YES;

}

How this method would look like in CPS style?

mikeash - 2010-02-06 06:32:42

Sat, 06 Feb 2010 06:32:42 GMT

No, you can put it wherever you want. Like (most of) the rest of C, all whitespace is equivalent. My preference is to leave it on the same line, but I couldn't tell you why that's different from everywhere else....

dwineman - 2010-02-06 06:18:59

Sat, 06 Feb 2010 06:18:59 GMT

Does the blocks syntax require the open-brace to be on the same line as the ^(...) ? If not, it might be slightly more readable without the mixed brace style.

mikeash - 2010-02-05 22:12:19

Fri, 05 Feb 2010 22:12:19 GMT

Well, Apple conventions don't get everything right, and as long as you don't let exceptions leak into code you don't control, then it doesn't matter what Apple wants you to do, the question is simply whether they work well for you. Of course, Apple's guidelines and the fact that the community mostly follows them means that almost any third-party code you work with won't be exception-safe, which will make using them routinely considerably harder.

August Joki - 2010-02-05 21:56:23

Fri, 05 Feb 2010 21:56:23 GMT

If I'm not mistaken Apple and/or convention has dictated that exceptions are meant for programming/-er errors, not for any old error. Another reason not to use exceptions to return useful runtime information.

mikeash - 2010-02-05 21:56:04

Fri, 05 Feb 2010 21:56:04 GMT

Nicholas Riley: The NSWorkspace methods aren't exact analogs, because they're using CPS for asynchronicity, and if you're writing asynchronous code then you have to use a block, function pointer, object/selector pair, etc. callback, and pass the results into it. Using blocks for synchronous continuations is fairly different, although this does show that Apple isn't afraid of this sort of thing.

Interesting note about Smalltalk. What happens if you use the ^ return operator after the enclosing scope has already returned?

jrk: One man's elegance is another man's unreadable, I suppose. Care to elaborate on why you find this to be unreadable?

jrk - 2010-02-05 21:17:02

Fri, 05 Feb 2010 21:17:02 GMT

well, it may be a nice way of doing it but overusing blocks makes the code unreadable.

I'd rather type 10 lines than have unreadable code. :(

Nicholas Riley - 2010-02-05 20:51:57

Fri, 05 Feb 2010 20:51:57 GMT

Thanks, good topic. A couple of mental comparisons this dislodged:

First, the two-callback-based system that Twisted Deferreds use ("callback" and "errback"): http://twistedmatrix.com/documents/9.0.0/api/twisted.internet.defer.Deferred.html) is an asynchronous implementation of what you describe, but it makes sense to see it used synchronously too.

NSWorkspace does have a couple of methods that provide an NSError to the callback (recycleURLs: and duplicateURLs:), as in your first example, so there is some possibility that this style will be used more in future.

- (void)recycleURLs:(NSArray *)URLs completionHandler:(void (^)(NSDictionary *newURLs, NSError *error))handler AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER;

- (void)duplicateURLs:(NSArray *)URLs completionHandler:(void (^)(NSDictionary *newURLs, NSError *error))handler AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER;

Finally, your comment about return not returning from the containing function made me laugh—I was just reading a blog entry where someone was trying to address Smalltalk having the opposite problem. Of course, Smalltalk being Smalltalk, it was actually possible to work around this by adding a method: http://www.cincomsmalltalk.com/userblogs/mls/blogView?entry=3441567670.

mikeash - 2010-02-05 20:01:37

Fri, 05 Feb 2010 20:01:37 GMT

Yeesh, I have no idea how I was able to make that typo so many times. Fixed, and thanks!

Sean - 2010-02-05 19:54:21

Fri, 05 Feb 2010 19:54:21 GMT

Thought you might want to know that you've got quite a few spots where you spell continuation as "contituation", which may not have been your intent.

Grzegorz Adam Hankiewicz - 2010-02-05 19:49:45

Fri, 05 Feb 2010 19:49:45 GMT

Man, you got me there until "This is nice and straightforward".