Closed kevinresol closed 8 years ago
The type gets transformed as well. So this should work:
@:async function bar(): Null<Int> {...}
Do you think the type transform is overkill here?
oops, I see! Hm... I think it is okay. Just missed that piece of doc 😛
Just got another problem, the following code fails to compile
package;
using tink.CoreApi;
class Main implements await.Await{
public static function main() {
new Main();
}
public function new() {
bar().handle(function(o) trace(o.sure()));
}
@:async function bar():Int {
var str:MyString = switch @:await foo() {
case Success(str):
str;
default:
"2";
}
return Std.parseInt(str);
}
@:async function foo() return Success('1');
}
abstract MyString(String) from String to String {}
Should be fixed in 0.0.4
Getting back to the return type issue, I am not sure if one day someone wants to explicitly specify the Failure type, maybe adding an optional meta @:throws(Error)
which will become the type of Failure
, how does it sound?
There's currently no way to guarantee the type of a failure. Because exceptions in other methods which are not caught are also passed down the line as failures. I was thinking of passing all failures as tink.core.Error, but it does makes catch()
in an async method kind of useless for other types.
How about this:
try {...}
catch(e:Error) __return(Failure(e))
catch(e:Dynamic) __return(Failure(Error.withData('Other error', e)));
Yes, that's what I'd do, but I mean handling the error aftwards:
try
@:await asyncMethod()
catch(e: Error)
//...
You can't differentiate by throwing a different type, all would be of type Error
. But on the other hand it's probably better than not knowing the type anyway.
I think I prefer having all failures typed as Error, that would preserve the error position and stack
Alright, I'll get this done in the next update.
Conversation continues here: https://github.com/haxetink/tink_await/issues/4
I am trying this code but it fails with: