hi,

i might be wrong, it looks likes to me that you want promise in go.

something like this https://github.com/chebyrash/promise

I personally don t like this pattern, even in javascript. but anyways,

example below looks really weird to me and difficult to figure out what 
means to 
"reject but not to return, so the execution continues?" 
https://github.com/Chebyrash/promise/blob/master/examples/http_request/main.go

in this version https://github.com/fanliao/go-promise 
same reject with naked return code that does not speak to me, 

but this https://github.com/fanliao/go-promise#promise-pipelining
seems to answer one of your request, to quit early before step2.
by wrapping step1 and step2 in order you might get the expected result.

I have my own answer, not a promise, to the question, example 
https://github.com/clementauger/st/tree/master/http
which i like because it helps to eliminate all this dead code that goes 
into my way.
in the given example i have only one err variable to manage, 
the early return is managed by the pipeline and with all the reflections 
involved,
the type assertions are gone and I just have to plugin the right func types 
et voilà.

its not perfect because type errors are runtime fatal but when it is setup, 
i like it.

in any cases, if i were beginner today, i would start by learning chan and 
go style at first
before i import patterns from other languages.

my 2 satoshis.

Le vendredi 8 mars 2019 14:02:31 UTC+1, whiteh...@googlemail.com a écrit :
>
> I'm really liking in Go that I can easily pass bits of code around, 
> 'closures'?  Apologies if I have terminology wrong, since I'm new here.
>
> For a typical asynchronous bit of code I like to pass in a 'func' for what 
> to do with the result, and also a 'func' to handle any errors.  
>
> I'm struggling to find a clean way to achieve a 'non-local return' i.e. 
> return from these closures and return the enclosing function too.
>
> https://play.golang.org/p/_ANPXKRzibq
>
> I had a look at the plan9 assembly stuff, and starting to suspect that 
> it's probably not possible?  
>
> So I'm wondering how readable my attempt is.  In Objective-C I would use 
> named parameters here of 'thenDo' and 'elseDo' to help the readability.  
> And I'm reluctant to try and duplicate that approach using a struct in Go.  
> But I suppose it's the dangling return that I least like...
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to