Error handling suggestion for @async about haxe-js-kit HOT 18 CLOSED

Here's an idea how to solve the different parameters:

// Assuming cb is Error -> String -> Void
var err, result = @async(err, null => cb) some.method()

I've done some testing, it was quite simple to implement, about 20 lines in util/Async.hx (including useful error messages).

from haxe-js-kit.

Honestly, this @async stuff is all about making the syntax easier, KISS-er, while keeping the macro basic. So I don't really like either of your proposals as-is.
OTOH, I would also like to see an elegant solution for error handling.

Also, I don't see any situation where cb shouldn't be Error -> String -> Void in the first place.
In this case, it's easy to skip the if and just cb( err, result ).
Then I think it would be nice to be able to @async cb( err, result ) = some.method(); ?

ITOH, maybe the following would be nice too, maybe closer to your first idea :
var cb( err ), result = @async some.method();
or
@async cb( err ), result = some.method();

Random / possibly irrelevant idea :

@async switch Soap.createClient('...') {
  case [null, result]: // do something with result
  case [err,_]: // handle error
}

I don't like it that much, though, because it adds indentation,
but I like the FP style of it.

Let's discuss :p

from haxe-js-kit.

About the second idea, how about:

@async switch Soap.createClient('...') {
  case @success( a , b ): // do something with a and b, given the callback has extra values
  case @success( a, b ) if a == "whatever": // guards
  case @error( err ): // handle error
  case @error( { code : 404, message : message } ): // pattern matching
}

I also don't want to go too far into something too complex,
because I'm pretty sure Juraj's tink_* has something similar, while much more solid and flexible...

from haxe-js-kit.

About the current syntax, and given all this :
I'd actually love to drop the var.

from haxe-js-kit.

misclicked

from haxe-js-kit.

I this idea, it's nicer than the one I suggested:

var cb( err ), result = @async some.method();

// And for callbacks with multiple parameters
var cb(err, null), result = @async some.method();

Dropping var is fine for me, but I don't think it makes things that much worse, since it's consistent with normal variable declaration.

If you think the syntax is ok, I'll start working on it and will make a PR.

from haxe-js-kit.

Unfortunately that is invalid syntax. :(

from haxe-js-kit.

Oh, the idea was great, So that's a no-no? :/

from haxe-js-kit.

We can probably figure something out ;)

from haxe-js-kit.

Ok, here's another take: Leaving KISS aside for a moment, I think semantics is also a quite important part of expressing yourself in code. So what would an uninitialized reader think about this:

var error = @async(error => callback) some.method();

Maybe: "An asynchronous call, errors goes to callback"

Compared to:

var callback(error) = @async some.method();

This looks more like a method call before the async call?

What would your interpretation be of these? Unbiased, I expect. ;)

Also: @async(error => callback) some.method() (without var) looks very good, but takes more work.

from haxe-js-kit.

I've been reading the whole thread again, and you're right it's all very confusing.

Back to your first proposal, I think it's already very misleading / error prone, mainly because it's not clear at all that there is a possible return / break: most of the time, with @async you expect the rest of your code to eventually run anyway.
It feels like some kind of hidden try/catch block...

Also, your proposal somehow assumes the first callback arguments is an error.
But @async can be used in many other situations, in theory :

{ 
   var req, res = @:async express.get("stuff/:id"); 
   res.end("Hello");
}

(Not really using it like this myself, not sure it even works like it should, but still...)

Also, the more I think about, the more I think having only an error in your callback is an anti-pattern.
I've never used it myself, and pretty much fail to see the benefit.
... except if you want to use promises ;)

So IMHO, the ultimate solution to your problem is in promises, really :p
That's why switch constructs popped to me at first.
How about that ?

var result = switch @async some.method() {
   case [null, result] : result;
   case [err, _] : return callback( err ); null;
}

In any case, I think your problem goes far beyond what @async is about,
and you should look into more complete FP-style solutions.

from haxe-js-kit.

True, it's based on the most frequent use case I have: If something goes wrong, pass it on and exit. It's not a general-purpose solution.

from haxe-js-kit.

PS:
With promisify, we could :

using Promisify;
var result = @async some.method.promisify()("arg1","arg2").catch( callback ).then(); 

Not even sure it works in the current @async implementation, but it should...

from haxe-js-kit.

What happened to KISS? :)

from haxe-js-kit.

Haha simple != concise :p

from haxe-js-kit.

Also true, but that code is rather an example of redundancy than conciseness. And with promises, it even turns into verbosity... I remember this discussion: https://groups.google.com/d/msg/haxelang/OiKbnxX4Wtk/Lh4PS2mSv84J

from haxe-js-kit.

I don't like promises either;
You are the one who brought me to promises with your error callback ;)

from haxe-js-kit.

No I don't want to catch anything really, in this case I want a return value, and a way of handling it in the Node callback style: http://fredkschott.com/post/2014/03/understanding-error-first-callbacks-in-node-js/

from haxe-js-kit.